Re: [boost] Exception lib?

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2006-07-09 16:20:40

On 7/9/06, Emil Dotchevski <emildotchevski_at_[hidden]> wrote:
> Felipe Magno de Almeida wrote:
>
> >> People use interfaces to allow for different implementation
> >> strategies. But the only implementation possible for
> >> get_exception_info is to use dynamic_cast!
> >
> > That is not the only reason. The implementation is just a detail from
> > a user point of view, things that expose that implementation become a
> > distraction to the user.
>
> Are you saying that the user knows that the object returned by failed<T>
> derives from both T and exception info, yet is distracted by the fact that
> dynamic_cast can be used to go from T * to exception_info *?

What I'm trying to say, but seems to be failing miserably, is that
failed<T> deriving from T and exception_info is too an implementation
detail. All the user should need to know is that throwing failed<T> he
is able to catch T& and get exception_info from this exception, where
he can add and retrieve data about the exception occurred.
Consequently, dynamic_cast is also an implementation detail which only
distracts the user from its goal:

>
> I'm not arguing that to have a function get_exception_info is
> unreasonable --  someone may have their reasons to define it. But IMO this
> is beyond the scope of the exception library.

No, I didnt mean that you were saying that. In fact, you already
agreed to create it. But what I'm saying is that such a function is
not only in the scope of the library but is also essential for a clean
interface. Where implementation isnt exposed on the interface, being
or not the only implementation possible is of no interest to the user.

[snipped]

> > If a user has to use dynamic_cast to be able to use the library then
> > it is part of the interface too, IMO.
>
> The users also have to use "throw" to use the library, and indeed it makes
> sense to hide it in a function (or a macro) because someone might want to
> compile with exception handling disabled. Or to not throw if it's Friday the
> 13th. But this is beyond the scope of the exception library.

The difference is that it is supposed to be a 'exception library', and
not a 'create a temporary that derives from T and something else
library', for which the dynamic_cast would be very sensitive. The
temporary deriving from whatever it derives is just a detail and
should be hided from users.

[snipped]

> > Now, using dynamic_cast to implement the
> > library is not a problem, since it is not of my concern as a user.
>
> Except that it is also reasonable for someone, after reading the
> documentation, to be puzzled why was it necessary to write
> get_exception_info when dynamic_cast is the only way it can be implemented.

I cant see why a user would ask such a thing. First of all he shouldnt
even know, unless he really really want to know, that dynamic_cast is
able to return an exception_info*.

> > As an example of good implementation hiding, boost::function uses
> > void* all over the place, albeit its interface is as clean and
> > straightforward as it can be. Even if void* is or isnt the only
> > implementation possible.
>
> There are many other examples that (correctly) hide implementation details
> behind an interface. There are many cases about which I'd agree that hiding
> a dynamic_cast behind an interface is necessary.

Looks like none of us is going to change its mind, so I believe we
should just let the discussion, if get_exception_info is or isnt
necessary, die.

>
> Regards,
> Emil

Best regards,
-- 
Felipe Magno de Almeida