I was quietly reading this thread, but I must respectfully but strenuously disagree with the premise that exceptions are "simply another kind of flow control". OK, semantically exceptions _are_ another type of flow control. Let's not jump down a rathole. But, in any language, exception-safe code is much harder to write than most programmers realize.

If every method is re-entrant, there is nothing to worry about because stack unwinding deals effectively with method-local state. But as soon as methods start affecting the longer term running state of a system, exceptions can easily leave that system in an inconsistent, possibly broken state.

True, bad code can do all that without the "benefit" of exceptions. But, even otherwise solid code can go horribly wrong because exceptions are thrown in a 3rd party library. Non-throwing code is much, much less likely to have that impact.

This is the reason why coding standards for systems with very high uptime requirements often disallow throwing exceptions. This can extend to disallowing use of libraries that throw (or taking pains to configure libs so that they do not).

Put another way, the "rare" nature of Exceptions (go figure) is implied in the sub-optimal treatment given by compiler writers to exception code paths. You sure as heck don't want to optimize Exceptions at the expense of the regular, non-Exception code paths!

At 12:03 PM 3/17/2010 -0400, John Redford wrote:
Which begs the answer to your question: Yes, people use die as goto. People use longjmp as goto. People use throw as goto. Exceptions have an association with concepts like "error case" and "should rarely happen"; but that is entirely wrongheaded. Exceptions are simply another kind of flow control. There are some low-level implications in terms of CPU efficiency, but it's just a matter of unwinding the stack until a point is found where some code should run, and then adjusting the instruction pointer. Within a single stack frame, it reduces to simply being a goto. Some languages (Perl, Java, others...) approach exceptions as "rare" and so have implementations that deter their use in high-performance scenarios -- so it's often a question not of program structure, but optimization and

Boston-pm mailing list

Reply via email to