On 7/9/06, Emil Dotchevski <emildotchevski@hotmail.com> 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