[phobos] Exception chaining

Max Samukha maxsamukha at gmail.com
Wed Jan 12 01:01:01 PST 2011


Thanks, Don. Looks like I completely missed the point of the discussion.

On Wed, Jan 12, 2011 at 10:46 AM, Don Clugston <dclugston at googlemail.com>wrote:

> No, that's unaffected by the scheme. The scheme only affects
> situations when an exception is thrown from inside a finally clause,
> when the finally clause is being executed because an exception had
> been thrown. It doesn't affect catch clauses, because once you're
> inside the catch, the first exception is no longer in flight.
>
>
> On 12 January 2011 09:27, Max Samukha <maxsamukha at gmail.com> wrote:
> > Will one be able to replace exceptions? A common C# scenario:
> >
> > class SystemException : Exception
> > {
> >     this(string msg, Exception innerEx) { this(msg, innerEx); }
> > }
> >
> > class SubsystemException : Exception
> > {
> >      this(string msg) { this(msg); }
> > }
> >
> > void system()
> > {
> >     try
> >     {
> >          subsystem();
> >     }
> >     catch (SubsystemException ex)
> >     {
> >         // subsystem exception is replaced with system exception and
> linked
> > to the latter
> >         throw new SystemException("a system exception", ex);
> >     }
> > }
> >
> > void subsystem()
> > {
> >     throw new SubsystemException("a subsystem exception");
> > }
> >
> > void main()
> > {
> >       try
> >       {
> >           system();
> >       }
> >       catch (SystemException ex)
> >       {
> >            // catch system exceptions and subsystem exceptions are
> available
> > via innerException property
> >            writeln("system: ", ex, ", subsystem: ", ex.innerException);
> >
> >       }
> > }
> >
> > As far as I understand, your scheme makes the above problematic.
> >
> > On Wed, Jan 12, 2011 at 1:50 AM, Andrei Alexandrescu <andrei at erdani.com>
> > 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.
> >>
> >>
> >> 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<andrei at erdani.com>
>  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
> >>>>> 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
> >
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110112/7a1fe256/attachment.html>


More information about the phobos mailing list