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 <[email protected]> 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 <[email protected]> wrote: >> >>> On 12 January 2011 09:10, Don Clugston <[email protected]> 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 <[email protected]> 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 >>>>> [email protected] >>>>> http://lists.puremagic.com/mailman/listinfo/phobos >>>>> >>>> >>> _______________________________________________ >>> phobos mailing list >>> [email protected] >>> http://lists.puremagic.com/mailman/listinfo/phobos >> _______________________________________________ >> phobos mailing list >> [email protected] >> http://lists.puremagic.com/mailman/listinfo/phobos >> > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
