get_error_info(T const &) returns a pointer instead of a const copy of the actual error_info it gets. This can be a potential headache to deal with especially in examining the error_info associated with the thrown exception. A proposed change would be to have get_error_info(T const &) return a const copy of the data, while get_error_info_ptr(T const &) would return a pointer as in the current version.
I suppose the behavior you propose for get_error_info is to throw an exception if the requested data is not available in the exception. But think about the situation you're describing: you catch an exception, and now you want to query it for error_info -- what good does it do for that context to throw an exception? Sure, there are use cases when you know an error_info must be present in the exception or you have a bug, but in that case it makes more sense to assert on get_error_info.
Although it might also take quite some effort to remove the runtime polymorphic behavior which relies on shared_ptr<>'s and virtual tables with info_base <snipped>
I never had any performance-related issues with this library, and I've been using it for more than a year now. Until we have evidence that we need to optimize, I would prefer to keep the implementation as simple as possible.
My concern with the use of shared_ptr<>'s is that in cases where an exception pertaining to "out of memory" conditions would arise, throwing a boost::exception and then having to allocate more memory just to encapsulate additional information would lead to undesirable termination.
Could you elaborate a bit more? Can you come up with a theoretical example that demonstrates your concerns? Thanks for you feedback! Emil Dotchevski