From: Josh Napoli (jnapoli_at_[hidden])
Date: 2007-10-20 00:57:29
> It would be useful for this purpose to provide an ability to iterate
> through the values or ability to pass a visitor or both.
> IOW, very long and hard to read lines. I would welcome some way to
> the exception in more compact form. I, however, do not have any
> how to do it.
> 4. I would like the ability to collect traces generated by what()
I've been playing around with Exception tonight and have a variation
with the following changes:
1. A more concise throw statement is desirable. In the variation, both
tagged and untagged fields can be added. The order of the fields is
preserved, using a linked list, instead of a map. Formatting of the
"what string" is still delayed until exception::what is called. The bare
minimum the amount of code needed to throw an exception with a message
that contains both a useful message for debugging and marked fields for
reporting back to the user.
throw exception() << "The frobknob is out of range: its value is " <<
error_info<value_tag>(value)<< " but the maximum value is " << max;
2. The potential for a null return value from get_error_info is going to
cause bugs. In this variation, this potential is eliminated by using a
visitor. A visitor can be applied to the fields to manipulate individual
values. The visitor is applied to each field with a matching type. The
field need not be tagged in order to be visited.
cerr << "frobknob value is " << x << "\n";
cerr << "max was " << y << "\n";
3. Sometimes you really want to throw a different exception type that
better describes the context of the error. In this case, the list of
fields from one exception can be added to a second exception. This
affects both exception::what and exception::visit.
throw can_not_load_file() << "could not open " <<
error_info<filename_tag>(filename) << " because " << e;
Source code is here http://joshuanapoli.com/exception
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk