On 10/6/14, 9:55 AM, monarch_dodra wrote:
On Monday, 6 October 2014 at 14:54:21 UTC, Andrei Alexandrescu wrote:
On 10/6/14, 7:24 AM, monarch_dodra wrote:
If your "catch" throws an exception, then the new exception simply
"squashes" replaces the old one:
//----
catch (Exception e)
{
thisMightThrow(); //Lose "e" here
throw e;
}
//----
That's code under library/user control, I'm talking about the
responsibility of the language. -- Andrei
Right. but if correct usage is so cumbersome no one does it right, then
it is 's/the responsibility/a flaw/' of the language.
Are we advocating then that code under user control should
systematically look like this?
catch (Exception e)
{
try
{
thisMightThrow(); //Lose "e" here
}
catch(Exception ee)
{
findLast(e).next = ee; //because e.next might
}
throw e;
}
Only if it needs to save that information. As far as the core language
is concerned, once an exception has been caught and made available to
the user, it's up to the user what to do with it. The point of chaining
is to not render information inaccessible to user no matter what they
do. This is a fairly basic remark.
Honestly, a good middle ground is to ditch chaining, but allow multiple
exceptions thrown at once. Subsequent Exceptions/Errors will just be
lost (sorry), with the exception that an Error will override an Exception.
If I redesigned D's exceptions, I'd change a bunch of stuff before that.
For the sake of argument, do you have any examples where a program has
used chaining?
Whenever an exception is converted to a string, the chained exceptions
should be part of it too.
Andrei
