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?
It wouldn't be difficult. The difficult thing would be to make a rule that's sensible and uncomplicated. The exception handler receives a list of exception records, some of which are Errors and some are Exceptions, and it has to determine if a given Object can catch that list. The chain of D objects is created only when we know we've caught them, so it can be constructed in any order. _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
