[boost] [review] Exception

From: Jarrad Waterloo (jwaterloo_at_[hidden])
Date: 2007-10-18 17:18:59

Please don't consider this a review of the Exception library. I am neither
for nor against it. This is more of my gripe session so please forgive me.

The exception library is like C++0x, "it is nothing that I asked and wished
for but everything I didn't know that I needed". This is both bad, more like
mildly disappointing cause of the 10+ year wait, and exceptionally good. My
3 wishes for C++ are standardized dll's, standardized reflection and
standardized stack traces.

The exception library touches on my 3rd wish/gripe. 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. 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. 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. 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.

P.S.
Add method "array<int> getStackTrace()" or "fillStackTrace(array<int>&)"
which would provide the trace of the EIPs would go a long way.
This could be an empty array when it couldn't be done as in inconsistent
register based passing of parameters.
It could be simple machine language stack tracing that can't handle inline
functions or more complex that relies on internal symbol information,
because some information is better than nothing.
The EIPs could latter be reconciled using MAP files or .pdbs.
The main thing is the pseudo-standard abstraction.