[phobos] Exception chaining

[Max Samukha]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110112/840b1b56/attachment.html>