The Right Approach to Exceptions

[deadalnix]

Le 19/02/2012 15:41, Andrei Alexandrescu a écrit :
> On 2/19/12 7:31 AM, Timon Gehr wrote:
>> On 02/19/2012 09:26 AM, H. S. Teoh wrote:
>>> On Sat, Feb 18, 2012 at 11:52:00PM -0800, Jonathan M Davis wrote:
>>> [...]
>>>> So, while at first glance, it seems like a good idea, I think that it
>>>> has too many issues as-is to work. It might be possible to adjust the
>>>> idea to make it workable though. Right now, it's possible to do it via
>>>> mixins or calling a function inside the catch, but doing something
>>>> similar to this would certainly be nice, assuming that we could sort
>>>> out the kinks.
>>> [...]
>>>
>>> I have an idea. What about "signature constraints" for catch, ala
>>> template signature constraints? Something like this:
>>>
>>> try {
>>> ...
>>> } catch(IOException e)
>>> if (e.errno in subsetYouWantToHandle)
>>> {
>>> ...
>>> }
>>>
>>> Just using IOException as an example. The idea is to allow arbitrary
>>> expressions in the constraint so whatever doesn't satisfy the constraint
>>> will be regarded as "not caught", even if the base type matches.
>>>
>>>
>>> T
>>>
>>
>> Nice.
>
> That helps. This quite nicely illustrates that types don't necessarily
> need to proliferate. Something not much more constraining can be done
> today:
>
> try {
> ...
> } catch(IOException e)
> {
> if (e.errno !in subsetYouWantToHandle) throw e;
> ...
> }
>
>
> Andrei

This wouldn't work because you'll erase teh stack trace.

An alternative is to create a new exception and chain with e. You 
discussed that in TDPL already. But It is worse than creating new types 
of Exception IMO, because now, you ends up creating 2 Exceptions. And 
you introduce the risk of someone silenting Exception, something that 
you don't want !