I think scope(failure) may need some work though, since it's modeled as a catch block.
Sent from my iPhone On Jan 12, 2011, at 12:46 AM, Don Clugston <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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<[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 >> >> >> _______________________________________________ >> 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
