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