[phobos] Exception chaining

[Sean Kelly]

Sounds fine to me.  I think the code is still in place to bypass the chaining functionality when SomeException.classinfo.init is thrown, correct?

On Jan 12, 2011, at 11:56 AM, Don Clugston wrote:

> 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
>> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos