[phobos] Exception chaining

[Sean Kelly]

I think scope(failure) may need some work though, since it's modeled as a catch block. 

Sent from my iPhone

On Jan 12, 2011, at 12:46 AM, Don Clugston <dclugston at googlemail.com> wrote:

> No, that's unaffected by the scheme. The scheme only affects
> situations when an exception is thrown from inside a finally clause,
> when the finally clause is being executed because an exception had
> been thrown. It doesn't affect catch clauses, because once you're
> inside the catch, the first exception is no longer in flight.
> 
> 
> On 12 January 2011 09:27, Max Samukha <maxsamukha at gmail.com> wrote:
>> Will one be able to replace exceptions? A common C# scenario:
>> 
>> class SystemException : Exception
>> {
>>     this(string msg, Exception innerEx) { this(msg, innerEx); }
>> }
>> 
>> class SubsystemException : Exception
>> {
>>      this(string msg) { this(msg); }
>> }
>> 
>> void system()
>> {
>>     try
>>     {
>>          subsystem();
>>     }
>>     catch (SubsystemException ex)
>>     {
>>         // subsystem exception is replaced with system exception and linked
>> to the latter
>>         throw new SystemException("a system exception", ex);
>>     }
>> }
>> 
>> void subsystem()
>> {
>>     throw new SubsystemException("a subsystem exception");
>> }
>> 
>> void main()
>> {
>>       try
>>       {
>>           system();
>>       }
>>       catch (SystemException ex)
>>       {
>>            // catch system exceptions and subsystem exceptions are available
>> via innerException property
>>            writeln("system: ", ex, ", subsystem: ", ex.innerException);
>> 
>>       }
>> }
>> 
>> As far as I understand, your scheme makes the above problematic.
>> 
>> On Wed, Jan 12, 2011 at 1:50 AM, Andrei Alexandrescu <andrei at erdani.com>
>> wrote:
>>> 
>>> I don't think that's helpful. It complicates the flow a lot because now
>>> understanding how the program acts depends not on the types anymore, but on
>>> what happens dynamically. Makes it more difficult, not easier, to write
>>> robust code.
>>> 
>>> If I throw a FileException, I must catch a FileException with
>>> catch(FileException) regardless of what collateral exceptions have happened.
>>> 
>>> 
>>> Andrei
>>> 
>>> On 1/11/11 12:31 PM, Don Clugston wrote:
>>>> 
>>>> I've thought about this a bit more. Another simple rule is, that an
>>>> exception chain can be caught if  and only if every exception in that
>>>> chain can be caught.
>>>> So, for example,
>>>> catch(FileException) will catch multiple file exceptions.
>>>> catch(Exception) will catch any exception (but not Errors).
>>>> catch(Throwable) catches Errors as well.
>>>> 
>>>> I went ahead and implemented this. Everythings seems to Just Work.
>>>> Will check it in shortly.
>>>> 
>>>> 
>>>> On 11 January 2011 18:30, Andrei Alexandrescu<andrei at erdani.com>  wrote:
>>>>> 
>>>>> Wow, this is incredible news!
>>>>> 
>>>>> Thanks Don for working on this. Solid exception handling is a huge
>>>>> selling
>>>>> point for D.
>>>>> 
>>>>> Regarding collateral throwables that are not Exception, good point (and
>>>>> I
>>>>> agree that the solution should be simple). TDPL doesn't discuss that
>>>>> issue,
>>>>> but it says that the initially-thrown exception is the "boss" and that
>>>>> everybody follows, so a possible design is to simply make the Throwable
>>>>> part
>>>>> of the chain.
>>>>> 
>>>>> I'd want to have chained exceptions still catchable by catch (Exception)
>>>>> because it would be a first to have the contents of the data influence
>>>>> its
>>>>> type. As far as the type system is concerned, catch (Exception) should
>>>>> catch
>>>>> Exceptions, whether or not they have a tail.
>>>>> 
>>>>> One possibility would be to move the Throwable to the front of the list.
>>>>> This also has its issues, for example the stack is unwound for a while
>>>>> and
>>>>> then not anymore (a Throwable is allowed to respect fewer rules than an
>>>>> Exception).
>>>>> 
>>>>> Ideas please?
>>>>> 
>>>>> 
>>>>> Andrei
>>>>> 
>>>>> On 1/11/11 1:57 AM, Don Clugston wrote:
>>>>>> 
>>>>>> I believe I have got TDPL exception chaining working correctly using
>>>>>> Windows Structured Exception Handling.
>>>>>> (This was far from easy!)
>>>>>> Central to making chaining work correctly, is that chaining must only
>>>>>> occur
>>>>>> when a collision occurs (not merely when two exceptions are in flight,
>>>>>> because one may be caught before it has any effect on the other). This
>>>>>> means that multiple chains of exceptions
>>>>>> may be in flight at any given time.
>>>>>> My code works in all nasty corner cases I've tested, including
>>>>>> multi-level collisions,
>>>>>> where two exceptions collide in a function, then collide again with an
>>>>>> even earlier exception chain in a finally block in a different
>>>>>> function.
>>>>>> 
>>>>>> So the general scheme appears to work.
>>>>>> But, there's something I'm unclear about. When should chained
>>>>>> exceptions be catchable?
>>>>>> They are very nasty creatures, and you really want to know when they
>>>>>> happen.
>>>>>> Presumably, an AssertError which occurs while processing an
>>>>>> FileException, should not be silently chained
>>>>>> and caught in the FileException.
>>>>>> In fact, should a chain containing an Error be catchable at all?
>>>>>> (If not, it still has to at least be catchable in the catchall handler
>>>>>> that wraps main()).
>>>>>> Many other schemes are possible, but I think it's important that the
>>>>>> rules remain simple.
>>>>>> 
>>>>>> One simple solution would be to make chained exceptions only catchable
>>>>>> by catch(Throwable).
>>>>>> _______________________________________________
>>>>>> phobos mailing list
>>>>>> phobos at puremagic.com
>>>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>>> 
>>>>> _______________________________________________
>>>>> phobos mailing list
>>>>> phobos at puremagic.com
>>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>>> 
>>>> _______________________________________________
>>>> phobos mailing list
>>>> phobos at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>> 
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
>> 
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos