I think this is a good rule. As you say, it is simple and easy to understand, and it ensures no critical exceptions are "lost" somewhere in a chain. I would be very dissatisfied if my program throws an Error and it is caught (indirectly) by a catch(FileException) clause.
-Lars On Tue, 2011-01-11 at 21:31 +0100, 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 <[email protected]> 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 > >> [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
