Re: [boost] Exception lib?

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2006-07-04 06:33:42

Kevin,

> - 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
> information
> 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 
class template.

> - 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 
the failure.

> - 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.

--Emil