Re: [boost] Boost and exceptions

Subject: Re: [boost] Boost and exceptions
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2012-06-26 04:02:15

> I would like to know that if I catch a "my_exception" that's what I'm
getting no more no less. My interface makes this much clearer.

The design of the language is inherently no less, but possibly more.

catch (X & x)

means X or derived from X. Ie X or more, no less.

Tony
<this is not an endorsement of any other opinions of the overall
discussion. Just wanted to highlight that point.
Also sorry for basically top-posting. Email on tablets still hasn't been
perfected>

Sent from my portable Analytical Engine

------------------------------
*From:* "Robert Ramey" <ramey_at_[hidden]>
*To:* "boost_at_[hidden]" <boost_at_[hidden]>
*Sent:* 25 June, 2012 2:50 PM
*Subject:* Re: [boost] Boost and exceptions

Peter Dimov wrote:
> Robert Ramey wrote:
>
>> hmmm looks to me that my program is not losing the type.
>
> Looks like you've rediscovered std::nested_exception?
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2559.htm

I did see this but didn't understand it.  A common problem with C++
libraries is that they're not well explained.

> This works but it supports a different (Java-like) style of exception
> handling. This same mindset has led to exception specifications -
> libraries have to only throw whatever is enumerated in their
> interface, so they are forced to wrap. With boost.exception, the high
> level catch still receives the original exception type, without needing to
> unwrap. It can then
> probe for further information if it likes, or it could ignore it (doesn't
> necessarily have to be rewritten as additional layers are inserted.)
>
> In other words:
>
> With wrapping:
>
> throw X
> catch X, throw Y(X)
> catch Y
>
> A new layer is inserted:
>
> throw X
> catch X, throw Y(X)
> catch Y, throw Z(Y)
> catch Z // this had to change
>
> With boost.exception
>
> throw X
> catch X, add info, rethrow X
> catch X

I didn't really think about this, but now you mention it I'm
convinced that my interface is far superior.

I guess this last catch X uses the multiple inheritace of the boost
exception
object to permit catch X rather than catch boost::exception which
syntatically looks clean.  But now you've got an interface - catch X
which actually is an X++.  To me this is very bad practice.  It hides
too much. It's not at all obvious whether or not one can extract
extra data from this - it depends on how the exception is thrown.
I would like to know that if I catch a "my_exception" that's what
I'm getting no more no less.  My interface makes this much clearer.

That is, I think
> catch Z // this had to change
is much better than
catch X // where X is really an X + some other data

One more thing to argue about.

Looking at my make_exception_wrapper, it might be possible to
use  the boost exception technique so on could replicate the
catch X behavior if he wanted to.  Really I didn't look at that aspect.

> Note how the final catch X doesn't need to change if another layer is
> inserted:
>
> throw X
> catch X, add info, rethrow X
> catch X, add info, rethrow X
> catch X

maybe - but this is a small benefit in exchange for the price of having to

a) wrap all the throws at the throw site
b) not being able add data to any throw exception.

Really, it's just not practical that for a library to be useful one has to
require
all the users to change their exception throwing code.  How does
boost exception deal with third party libraries for which we don't even
have the source code?

FWIW - The assertion was that it was not possible to implement functionality
of boost exception without wrapping exceptions at the throw site. I believe
I
have shown a counter example to this assertion.  This was my goal and
I feel I've fullfilled it.  To ask more of me here would be moving the
goalposts.

I'm sure if I had nothing else to do, This could be crafted into a slicker
interface.  But this is beyond the scope of the original question.  Actually
I'm sure this technique could be integrated into boost exception - at a cost
of changing some of the boost exception interface, which would yield
a non-intrusive, more robust, more portable library.

Robert Ramey

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost