Re: It could always be worse.
There are those who say, (and I tend to agree) that this is exactly why exception handlers are the devil's spawn, combining the worst elements of gotos and segfaults! Yes, they _can_ be used, carefully, in such a case - but you are leaving all context behind, eliminating any possibility of maintaining state except by manual labor. There was an essay ... in fact there have been several:
> "Exception handling introduces a hidden, "out-of-band" control-flow possibility at essentially every line of code. Such a hidden control transfer possibility is all too easy for programmers to overlook – even experts. When such an oversight occurs, and an exception is then thrown, program state can quickly become corrupt, inconsistent and/or difficult to predict (think about an exception unexpectedly being thrown part way through modifying a large data structure, for example)."
> "Exception handling does not fit well with most of the highly parallel programming models currently in use or being explored (fork/join, thread pools and task queues, the CSP/actor model etc), because exception handling essentially advocates a kind of single-threaded "rollback" approach to error handling, where the path of execution – implicitly a single path – is traversed in reverse by unwinding the call stack to find the appropriate error handling code."
> "The reasoning is that I consider exceptions to be no better than "goto's", considered harmful since the 1960s, in that they create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's:"
> "The doctrine of object-oriented programming dictates that exceptions are the mechanism of choice to raise (and, possibly, handle) severe error conditions that cannot be safely ignored by the client code. Let me just take a step back to explain why I think exceptions are all but inappropriate in most situations by definition."