Boost logo

Boost :

From: scleary_at_[hidden]
Date: 2002-06-14 08:57:18

From: Ted Byers [mailto:r.ted.byers_at_[hidden]]
> I find my traceable exceptions of value, since the only time I am
> in a trace is when something goes awry, in which case, or at least for the
> more serious cases, I'll have an exception to deal with, and my traceable
> exceptions will tell me what led up to the problem.

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 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. If you're a Borland user, the first catch() for
a VCL object will make this translation; if you don't use the VCL, this
translation is never made. I'm not sure how MSVC handles this.

Also, I did not want stack tracing added to other "non-fatal" exceptions. I
do use exceptions to indicate errors for operations that can be retried, and
in one case I even use an exception as an end-of-input designator for a file
parser (whose design is patterned after Iterators in the Python language).
Adding stack traces for these exceptions is just adding overhead.

I think the biggest issue, though, is intrusive vs. non-intrusive design.


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