Re: [boost] [review] Exception

From: Emil Dotchevski (emil_at_[hidden])
Date: 2007-10-18 18:17:33

> <snip>
> It is great that a
> filename can be associated with an exception thrown at a lower level that
> didn't know that information. Yet, the additional information is purely
> optional. There is no guarantee that the rethrower ever added the
> information. As such the final catcher will have to do a lot of tests to see
> if the information exists.

There is no guarantee in general, meaning that you can't write a
universal final catcher that deals with exceptions regardless of what
they are, what context they were created in, and what contexts they
passed through.

However, catchers don't need to be universal. Consider this example of
3 contexts:

1) Mid-level code opens a file, creates a serializer object, and calls
a low-level library to read something.

2) The low-level lib throws an exception without a file name because
it's using the serializer object, which in principle could be reading
from some non-file source.

3) High-level code catches the exception and handles it.

In this scenario, 3) doesn't need to deal with exceptions that lack a
file name, because the mid-level context should add it (if a file name
is missing, we have a bug.) A reasonable behavior is to assert in this
case.

In principle it is possible that at 3) we catch an exception that
legitimately lacks a file name, but that simply means that it did not
pass through 1). Still, the solution doesn't need to be universal. At
some point, someone needs to "know" about all possible exceptions that
can reach a particular high-level exception-handling context, and
handle them.

> However, it doesn't seem to do anything to get me
> one step closer of generating a stack trace when the exception is thrown or
> at least when the boost::exception is constructed.

Stack traces can be stored in boost::exception just as any other
error_info. If a particular compiler/platform provides an interface
for obtaining a stack trace, I don't see why it shouldn't be captured
and stored in the exception by the boost::exception constructor.

> There are no
> callbacks/hooks to add this capability to everything that derives from
> boost::exception when the data is not optional. It is not good enough for
> such stack trace and potential other information to sometimes be there as it
> is information that should always be available.

If some information is not required at the point of the throw, but is
required at the point of the catch, you assert() on get_error_info.

If some information is required at the point of the throw, then you
make your exception class' constructor take that information as
argument(s).

> It is as specialized as my
> wish and maybe doesn't deserve the name boost::exception. Maybe it should be
> renamed to boost::map_exception, boost::tuple_exception,
> boost::additional_optional_information_exception or something similar and in
> the future an exception class that provides stack traces can be called
> boost::stacktrace_exception. Let's keep, reserve, the word boost::exception
> for the day when it handles most everyone basic exception needs; both sets
> of functionality.

std::exception does not solve all of your problems either, but it does
"deserve" its name because it's purpose is to be the universal base
class of all exceptions.

boost::exception can be viewed as an extension of std::exception which
adds an important piece of missing functionality. If you feel that
boost::exception lacks other important functionality to "deserve" its
ambitions to be the universal base class of all boost exceptions, the
solution is not to rename boost::exception, but to add the missing
functionality.

Emil Dotchevski