Re: [boost] Exception lib?

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2006-06-22 14:09:51

> I liked very much your idea, but something bothers me.
>
>>
>> catch( read_error & x )
>> {
>>     if( info * xi = dynamic_cast<info *>(&x) )
>>         if( file_name * fn = xi->get<file_name>() )
>>             ......
>> }
>
> IMO, this dynamic_cast should be hided by the library.
> How about:
>
> catch(read_error& x)
> {
>  if(info i = try_get_info(x))
>  {
>    // ... do something.
>  }
> }

In fact, with a function like this you could completely hide the info class 
from the public interface, right?

But the fact that class info is a public base for the exceptions being 
thrown is a key feature of the library. It makes it possible to catch(info 
&) in places where you don't care what went wrong and simply want to add 
context information to any exception that passes through.

I think that because class info will always be a public base of all 
exceptions, dynamic_cast will always work, and there's no reason to provide 
an alternative for achieving the same thing.

> There should be a way to inspect what there's in the info object too,
> IMHO.

You mean, a way to enumerate all contained boost::any objects? But what can 
you do with a type_info and a void pointer?

I think a more useful function would be to automatically compose a textual 
description of the stuff that's in the info object. I thought about this, 
but decided that formatting a message for the user is beyond the scope of 
the exception lib. Consider that such a message has to be localized, too!

That said, it's probably a good idea to design a system that automatically 
composes a textual description, even if it is only useful for dumping in 
error logs and stuff.

But such a system would complicate the info class. You wouldn't be able to 
stuff just any object in it, because 'infos' will have to implement some 
virtual function to convert them to strings. And I like how my fread wrapper 
stuffs a boost::weak_ptr<FILE> in the exception, just because it could be 
useful to someone higher up the stack.

But if you have ideas about this, I'm very interested to hear about them.

--Emil