Charlie Reitzel wrote on Wed, Mar 17, 2010 at 07:11:55PM -0500: 
> 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. 

FWIW, in C++ as of today's gcc, a function exiting with a thrown
exception is roughly 1000 times more expensive than a regular
call/return, and that is with one single object to clean up on the
stack that sets one global variable.  I can provide my little test

I just had to kill some instances in my employer's codebase that were
using thrown exceptions as regular flow control.  They also make
debugging harder since gdb by default jumps on them.

> But, in any language, 
> exception-safe code is much harder to write than most programmers realize.

You word it like that means exceptions are hard.

But it is even harder (and usually much uglier) to do the same "make
safe for continued program execution after an error" when attempting
to do cleanups around stacks of regular return calls that you have to
"shortcut" to.

> 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).

Wouldn't that mean "don't let exceptions escape out of the library"?
Not that I like either.

In my mind, not using exceptions is almost a guarantee that there are
resource leaks.  The only reason why this can halfway work today is
that we have humongous amounts of virtual memory and can have
thousands of file descriptions.

Martin Cracauer <>
FreeBSD - where you want to go, today.

Boston-pm mailing list

Reply via email to