Boost logo

Boost :

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"

Boost list run by bdawes at, gregod at, cpdaniel at, john at