Boost logo

Boost :

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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at