Re: [boost] Boost and exceptions

Subject: Re: [boost] Boost and exceptions
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2012-06-23 16:29:54

On Sat, Jun 23, 2012 at 12:11 PM, Robert Ramey <ramey_at_[hidden]> wrote:

> John Maddock wrote:
> >> Why does the serialization library have to include code from boost
> >> exception in order to do this?
> >>
> >> You can use boost exception at the same place, catch
> >> the standard exception that the serialization throws, construct
> >> you're own boost exception and continue on.
> >
> > No!!!!
> >
> > Misses the whole point - Boost.Exception allow you to annotate an
> > existing exception without loosing the original information - and
> > that includes the *type* of the original exception.
>
> Here is what I don't get.
>
> When the serialization code was written I
> decided that the exception mechanism was that right way to go.
> I realized that just a "generic" exeception wouldn't included enough
> information so I created boost::archive::exception and extra data
> specific the this kind of acception.  The file name is
> archive_exception.hpp.  This exception type has most of the
> useful information regarding the exception.

That's fine.

>  Some was excluded
> as it would make the type "heavier" than I wanted or would
> have required data types which might use the heap or other resources
> which of course would be a disaster.

Calling boost::throw_exception doesn't allocate anything from the heap.

That said, it's not a problem to attach heap-allocated data to exception
objects. Note that many compilers allocate the exception objects from the
heap anyway.

> So - boost::throw_except is changed and.... what? I already included
> all the useful information I can add.  How can boost::throw_exception
> add to this on it's own? What can it possible do that's useful?

For example, if Boost Serialization calls boost::throw_exception, an
application that serializes data that comes from a web site could store the
web address, the user name, port number, or whatever else the application
needs to handle the exception.

>  If the user want's to, he has the option or using
> rtti type_id to get the type - but he's not forced to if he want's to
> keep his code lean and mean.
>

For 100th time, boost::throw_exception works with RTTI off.

> your code when you eventually can eventually rethrow
>
> catch (std::exception e){
>    BOOST_EXCEPTION_THROW_EXCEPTION(e)
> }
>

There are two problems with this code.

First, the catch as written slices, erasing the dynamic type of the
exception. You should never catch exceptions by value.

Second, even if you catch std::exception & obj, throwing obj will slice,
erasing the dynamic type of the original exception.

If the point of this catch is to translate the type of the exception
object, it has to look like:

catch( foo & e )
{
  BOOST_THROW_EXCEPTION(my_foo(e));
}
catch( bar & e )
{
  BOOST_THROW_EXCEPTION(my_bar(e));
}
catch( foobar & e )
{
  BOOST_THROW_EXCEPTION(my_foobar(e));
}
catch( ... )
{
  assert(0);
}

And of course this nonsense has to go around every call to Boost
Serialization.

WHY?

 > Now consider that the serialization code includes some use of
> > Boost.Filesystem, Boost.Regex (filename parsing) and heaven known
> > whatever other dependencies the object being [de]serialized depends
> > on (presumably an object being deserialised could throw any exception
> > Boost is capable of). If all those exception objects uniformly derive
> from
> > boost::exception
> > somewhere in their object hierarchy, then you catch *one* exception
> > type, annotate it, and rethrow.  All the original type information is
> > retained, clients can catch the boost::exception and enumerate all
> > the information it holds, or they can catch something more specific
> > like boost::archive::exception and work from there.
>
> How is this different from using std::exception ?
>

You can't add your own stuff to a live std::exception.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode