I just saw this question asked on SO: Does try/finally ignore exceptions?
It's really similar to, or duplicate of: In C# will the Finally block be executed in a try, catch, finally if an unhandled exception is thrown? and its brethren. (There have been over 70 views and no one thinks it's a duplicate.)
At what point is a question a duplicate? Is there a clear set of guidelines/rules? Or is this a touchy-feely thing?
Related: Duplicate question etiquette: to delete or not to delete?
I would imagine that when a question is asking the same thing (and likely to get the exact same answer), then it should be classified as a dupe.
A lot of it is touchy feely, however, and I feel a lot of people accidentally classify something as a dupe even when there are some subtle differences which may not make it the same and is asking for something a bit different. There seems to be a lot of reflexive knee-jerk reactions when it comes to voting to close for duplicate reasons.
If a new question is answered by the answers to an old question, I will generally consider it a duplicate. The exception to this is when an answer to the new one does, or potentially could add a significant amount of useful information - in that case, it's worth editing one or both to draw a clear distinction between them, and perhaps a "See also:" crosslink.
Jeff defined some different classes of duplicates in one of his blog posts. He says about "Borderline duplicates":
There’s often benefit to having multiple subtle variants of a question around, as people tend to ask and search using completely different words, and the better our coverage, the better odds our fellow programmers can find the answer they’re looking for.
Handling duplicates is also discussed in this other MetaSO question.
I know I saw a blog post about this ... ah here it is : Handling Duplicate Questions 04-28-09 by Jeff Atwood !
It's worth noting that the first question is C#-specific whereas try/finally is a construct that exists in other languages (eg Java). I can't think of any language-specific issues with this but that doesn't mean there aren't any. Back in the Java 1.4.2 days, try/catch was horribly expensive so performance was a valid consideration (fixed in Java 5+). Not that performance was a focus of the question (either one) but it's that kind of thing that can differentiate otherwise similar questions.
The two questions are certainly close though.
