Thanks, Don. Looks like I completely missed the point of the discussion. On Wed, Jan 12, 2011 at 10: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
