From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2006-07-04 06:33:42
> - I don't like the word failed as in 'throw failed<my_error>' it seems
> strange to throw a "failed error", that's the way I read it anyway. I
> can't come up with a better one right now though.
English is not native to me, but the way I read throw failed<read_error>()
is that the function (that throws) failed due to a read_error. That was my
intention anyway. :)
> - There should be a way to iterate over all exception_info objects
> contained. This is useful in a case where you don't know what
> was attached to the exception. Then you just want to print everything
> that can be translated via lexical_cast to a logfile to get the
> maximum information on the exception regardless.
Just to clarify: there is a single exception_info sub-object in each
exception object. In the current implementation, I could implement iteration
over its content, but this iteration would only get you a void * for each
object stored in it. Not very useful. On the other hand, it is useful to
iterate over all info_wrapper<string,T> stored in an exception info. I'll
think about implementing something along these lines. This I think is the
strongest argument for changing the lib to using string IDs to identify
stuff stored in exception_info, instead of tag types and the info_wrapper
> - I don't think it's a good idea to have a tag mechanism to access
> each info field. It's inconvenient having to declare the tag. Of
> course strings can be abused.. but that's C++. I believe simple
> string keys are enough and very descriptive and easy to use.
I guess I was overly concerned with abusing strings, but that's because in
my experience as game programmer I've seen strings abused quite often.
Several people have made similar comments, I think I'm convinced.
> - why not create an operator << () that automatically does the
> wrapping via exception_info_wrapper instead of having a
> wrap_string(), wrap_errno()...
Because, in the current implementation, you can stuff anything in an
exception_info, not only exception_info_wrapper objects. In the example at
the end of the documentation, you can see a weak_ptr<FILE> stored in the
exception_info -- just because it's one of the things that is relevant to
> - I don't like the dynamic_cast involved in getting the info object.
> It may be enough to hide it in a small inline function if
> (exception_info* xi = get_exception_info(&x))
Yes, I agree the dynamic_cast is ugly. I left it that way simply because I
didn't want to have two ways to get to the exception_info. Note that even
with get_exception_info, the documentation pretty much tells you that a
dynamic_cast will work just as well. But I guess it's ugly enough to justify
adding get_exception_info function.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk