Re: [boost] Exception Visitor

From: Ames Andreas (Andreas.Ames_at_[hidden])
Date: 2006-07-28 07:44:38

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Alexander Nasonov
> Sent: Friday, July 28, 2006 12:54 PM
> Subject: Re: [boost] Exception Visitor
> 
> Please, NO!
> It's my experience that one catch(...) in a program may be a 
> source of many annoying glitches that users report 
> periodically but developers don't understand what's going on.
> Removing this often helps. Users start reporting crashes. 
> Most difficult at this stage is to find a user who is able to 
> run Dr. Watson, check 'Create Crash Dump File' and send a 
> dump to developers :)
> 
> Also worth noting that SEH is not standard C/C++.

FWIW, I'd like to strongly second that.  When catching SEH
exceptions (like catch(...) does), predictable behaviour is only
possible if you compile for 'asynchronous exception handling',
which according to the docs increases the generated code size (I
don't know about the runtime performance cost).  If you compile
for 'synchronous exception handling' (the more usual thing, I
believe), you should either be prepared to live with bad cleanup
of the stack or you install a global SEH-exception handler in
each thread you start, which does nothing but rethrow and
therefore crash the app.  IMHO, that's nothing a library should
impose on its apps.  Anyway, I fail to see what's the benefit of
catching segfaults _as the default behaviour_ (that's not to say
there aren't applications that need to do).

FWIW again, I won't use a solution which includes catch(...)
anytime soon (and esp. not if it's done in a pervasive manner).

cheers,

aa

-- 
Andreas Ames | Programmer | Comergo GmbH |
Voice:  [phone] | ames AT avaya DOT com