Exception considered harmful...
Oh joy, someone else who believes "try/except/finally" is the silver bullet for all ills.
Exceptions are simply another way of writing GOTO. If you disagree, riddle me this: what other instruction forces execution to jump to an arbitrary location in code with no return path...?
This isn't necessarily a bad thing, but as other people have said, the problem is knowing where you came from, and what happened when you were in there. Suppose your pseudocode looks something like:-
* Create an array of handles
* Get a load of handles to resources, and put them in the array
* Create an array for intermediate data
* Do some processing based on the resource data, using the intermediate array
* Create another array of handles
* Get a load of handles to resources, and put them in this array
* Store processing results in the resources from these handles
* Free handles and delete arrays
Now add an exception for "out of memory" covering this entire section of code. What do you clean up in the exception handler? If the arrays are global then great, but if the arrays have local scope (and the intermediate array almost certainly should, if you're competent) then you're screwed - you can't get at the stuff you need to clean up, so you get memory and handle leaks. The better answer is that you nest your code so that each allocation has an associated clean-up operation. That way you have maintainable and reliable code - you know *where* the clean-up is happening, and you know the clean-up *is* happening. You can still use exceptions to handle failure if you want, but each "allocate" operation (be it memory, resource handles or whatever) needs its own exception handler to do the targetted clean-up that's required.
The key point now is that since clean-up has to happen regardless of success or failure, a single point of exit usually gives you more efficient and maintainable code, because you only do the clean-up in one place. Et voila!
Sure, there might be circumstances where clean-up requires some separate return path. But usually you're looking at a maximum of two return paths then, for success or failure.
I've seen quite a few people who are great believers in "try/except" solving everything. Almost always, they're Windows programmers who've never had to handle errors properly. Their attitude is that when things go wrong, the program crashes, Windows cleans up memory when the program dies, and the user launches their program again. Great. Except that when you transplant this attitude to embedded apps (mobile phones, for example), you don't have Windows cleaning up after you. Best case, you get memory leaks - worst case, you get memory stomps and CPU exceptions. And this simply comes down to sloppy coding practises which are mitigated by the defense-in-depth which Windows (or any other PC OS) provides.
An embedded software programmer knows better - through bitter experience, they know that if it can go wrong, it will go wrong. If it can go wrong, you'll have some error indication to let you know how it went wrong, so if there's an error indication available you *always* check it. Failure to check errors and do appropriate clean-up is the classic sign of a Windows programmer, reinforced by all Windows tutorial books which ignore the error returns from functions.