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.
Andrei
On 1/11/11 12:31 PM, 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
