RE: [boost] Exception specifications in smart_ptr.hpp

From: Bill Wade (bill.wade_at_[hidden])
Date: 2000-07-24 09:50:33

> From: David Abrahams [mailto:abrahams_at_[hidden]]
> Sent: Friday, July 21, 2000 7:47 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Exception specifications in smart_ptr.hpp
>
>
> From: "Bill Wade" <bill.wade_at_[hidden]>
>
> > A third possible use:
> >   throw(A,B,bad_exception)
> > is a convenient shorthand for
> >
> >   try{ stuff_that_might_throw(); }
> >   catch(A&){ throw; }
> >   catch(B&){ throw; }
> >   catch(bad_exception&){ throw; }
> >   catch(...){ unexpected(); }
> >
> > If you really do need to map all possible exceptions to a small set of
> > exceptions (say those exceptions that you know how to send via smoke
> signals
> > with an agreed-upon protocol), the notational convenience is handy.

> I suspect that you're not really saving yourself anything in this case. If
> you look at the code which sends the allowed exceptions via smoke-signals
> I'd lay odds it looks a lot like the code above you are writing a
> shorthand
> for ;)

But the smoke-signal try() block is only invoked when my function is called
remotely (a try block outside of my function).  If my function is called
in-process I've probably got a faster communications mechanism.  However the
code in the catch(...) block is always needed in order to enforce my
function's contract.

> You could just drop the exception-specification and send a
> bad_exception via smoke signal (however you do that!) in your catch(...)
> clause.

But with the exception-specification I don't need to write the try/catch
stuff.  This is a notational (and maintenance) convenience.

For me, at least, this discussion is mainly academic.  Too many compilers
mishandle throw specifications for them to be on my "portable features"
list.