The way I'd recommend handling this would be hugely different depending on the nature of the application. Ask yourself the key questions:
- How often are users going to be deleting an entry in typical use?
- How much will be lost by an unwanted delete?
If you're designing an application where deletes are rare, such as when they are only be used in the case of correcting a user's error, then it is usually a better choice to make deletes more difficult. Little will be lost by making the user do a lot of work.
If you're anticipating frequent use of the deletion process, however, making the user do more work becomes a major issue. Examples would be a mailbox or a queue or task list where the user deletes items as they get processed or completed.
Also consider the cost of information deleted in error. In the case of an email or messaging inbox, a deleted message may contain irreplaceable information. On the other hand, if the deletions are just from a user-generated list of short items (such as the list of species on an eBird observatiion, or the list of tags on a blog post, etc.) then the cost of deletion is low.
If the stakes of deletion are high, these are best avoided.
tohster's solution with an "undo" button is accepted best practice in some situations, but it is sometimes a lot more work to implement an "undo" button.
I personally only recommened implementing an "undo" button in the scenario where typical use involves frequent deletion AND stakes of deleting in error are high. An example would be a mail program, and this is probably why programs like gmail use this approach.
For something where deletions are rare, a cumbersome confirmation process is not a big imposition on the user.
And for something where accidental deletions have low stakes, you may not even need to confirm, and if you do, it's not a big deal if you allow double clicks or keypresses.