RE: [boost] Re: Re: improved assertions?

From: scleary_at_[hidden]
Date: 2002-06-18 15:18:17

> From: Hendrik Schober [mailto:boost_at_[hidden]]
> <scleary_at_[hidden]> wrote:
> > [...]
> > I toyed with traceable exceptions back before I decided to 
> go the other way.
> > Like you, I was only interested in a stack trace when something goes
> > *really* bad -- like my program is about to fatally exit.
> 
>   But what is "really" bad when you do event based 
>   programming?

For my programs, I define "really" bad as any exception that propogates to
the main loop of the thread.  But there's no reason someone else can't
define some other definition.

>   Bottom line: In non-critical, interactive, event-
>   driven applications, if one event fails, let the 
>   users decide whether they want to restart the app 
>   or go ahead and try another event. 

My solution was initially designed to work in my limited problem domain (I
didn't think I'd ever be sharing this code...), and I work with
system-critical, (mostly) non-interactive, event-driven applications.

> > But now consider: on the Win32 platform, in the case of an 
> access violation
> > (the most common "fatal" programming error), an OS 
> exception (not a C++
> > exception) is raised.  Traceable exceptions can only trace 
> the stack down to
> > the point where the OS exception is translated to a C++ 
> exception, not at
> > the actual point of error.  
> 
>   There's a WinAPI function that you can use to 
>   install a handler for those events. 

Which I have not gotten to work with Borland.  And this is beside the point
I was making: that traceable exceptions cannot trace the stack *after* the
translation is made.

> > I think the biggest issue, though, is intrusive vs. 
> non-intrusive design.
> 
>   I like the previously mentioned idea, that these do not 
>   exclude each other and can co-exist. 

Agreed.

        -Steve