scope() statements and return

[Andrei Alexandrescu via Digitalmars-d]

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