[Exceptional C++ Style] Item 12: Exception Safety: Is itWort hit?

[Ric Parkin]

From: Kevlin Henney <kevlin at curbralan.com>
> Ric Parkin <ric.parkin at ntlworld.com> writes
> >
> >Hmmm, is one way to have a signal handler and throw an exception from 
> >that? I know that's rather naughty, but we're deep into specifics 
> >anyway.
> 
> So naughty that some systems crash when you do it :->
> 
> I remember trying this out on one platform (Ultrix) many years ago (as 
> you might guess from the OS) and it worked, so I promptly tried it out 
> on another (OSF/1, which became Digital Unix, which became Tru64) to 
> check for de facto portability: it crashed. The exception actually 
> missed main: signal handlers are not necessarily executed on the same 
> stack as the thread they originated in, so unwinding in the hope you 
> reach main may well prove fruitless.
> 
> And then, eventually, the standard came out and confirmed that is was a 
> definite no-no.

Just to be clear, I knew it's a Standard No-No, but wondered if it might work on some systems, and could be used to do something when Bad Things Happen for them only. Your answer above indicates some where it might work, and some where it definately won't.

One nice thing about the windows system is that it's defined how you can put your own handler in. The standard ones either just abort the program, allow you to attach a JIT debugger, or throws a C++ exception (of undisclosed type). Alternatives that could be done include dumping the stack, doing a core dump like unix, throwing a StructuredExceptionDuringTest exception, setting some global failure flag and terminating the current thread, etc.

A pity this is surprisingly little known - I've had arguments with people who insisted that catch(...) was Evil because "it always catches OS exceptions" when that is an effect of the particular handler that MSVC uses with certain compiler options

Ric


-----------------------------------------
Email provided by http://www.ntlhome.com/