[phobos] Exception chaining

Don Clugston dclugston at googlemail.com
Wed Jan 12 11:56:40 PST 2011


On 12 January 2011 16:01, Sean Kelly <sean at invisibleduck.org> wrote:
> Two errors could still cause confusion though.

Yeah. Though how much of a problem is it?
Catching an Error is a nasty action. A nothrow function is permitted
to throw an Error because it is non-recoverable, so catching it in
order to recover is somehow a bit shady. (Should it be legal to catch
an Error in a @safe function?)

This whole exception chaining idea is based on the premise that it's
the first error which is the important one. I do think that applies
even to Errors; I think it's still better than C++'s replacement
strategy. Can you think of any other way of doing it?

We could say something like, "catching an Error is not something which
should be done lightly. In the rare cases where it is necessary, you
should _always_ check for secondary Errors which may have occurred
while processing the first one."

Anyway, I've implemented this second approach. If anyone has ideas for
anything better, please speak now, because I want to check it in and
move onto something else. (I just want to leave it in a close-enough
state, that you can take over from to do the finishing touches).


>
> Sent from my iPhone
>
> On Jan 12, 2011, at 12:55 AM, Don Clugston <dclugston at googlemail.com> wrote:
>
>> On 12 January 2011 09:10, Don Clugston <dclugston at googlemail.com> wrote:
>>> How about this rule:
>>> ---
>>> If all collateral exceptions are derived from Exception, the 'boss' or
>>> Master Exception is the first exception thrown.
>>> Otherwise, the first Error (or Throwable non-Exception) is the boss.
>>> The exception, including all collateral exceptions, will be caught by
>>> the first handler who can catch the boss.
>>> ---
>>>
>>> Two issues:
>>> * If the boss is a collateral exception, we still need a way to find
>>> out what the first exception was. Maybe need to add a 'first' (or
>>> 'prev') member to Throwable?
>>
>> Or, the chain could simply be:
>> boss -> exception1 -> exception2 -> BypassThrowable -> exception3.
>>
>> Where BypassThrowable is a class which acts as a placeholder for the boss.
>>
>> This would be the simplest interim solution, since it doesn't require
>> any code changes elsewhere, and would allow the
>> existing error messages to continue to work correctly.
>>
>>
>>> * It is still possible to throw an Object which isn't derived from
>>> Throwable. Can we disallow this?
>>> (We could throw a "NoThrowableError" if such an object is found to
>>> have been thrown (can happen via casting)). This would remove some
>>> really nasty corner cases.
>>>
>>>
>>> On 12 January 2011 01:10, Andrei Alexandrescu <andrei at erdani.com> wrote:
>>>> On 1/11/11 4:03 PM, Jonathan M Davis wrote:
>>>>>
>>>>> On Tuesday, January 11, 2011 15:50:52 Andrei Alexandrescu 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.
>>>>>
>>>>> I agree as long as it's other Exceptions that have been thrown. But
>>>>> Errors?
>>>>> Aren't they typically supposed to kill your program?
>>>>>
>>>>> - Jonathan M Davis
>>>>
>>>> I agree that non-Exception Throwables are an out-of-band method of
>>>> communication that deserves special attention.
>>>>
>>>> Don, would it be difficult to make a non-Exception Throwable thrown during
>>>> unwinding essentially come to the top of the foodchain and save everything
>>>> in its tail?
>>>>
>>>>
>>>> Andrei
>>>> _______________________________________________
>>>> 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
>


More information about the phobos mailing list