DIP 1002 (TryElseExpression) added to the queue

[Steven Schveighoffer via Digitalmars-d]

On 9/28/16 7:58 AM, John Colvin wrote:
> On Wednesday, 28 September 2016 at 07:47:32 UTC, Andrei Alexandrescu wrote:
>> * The "Breaking changes" section should include how the following
>> change in semantics would be addressed. Consider:
>>
>>   try
>>     if (expression)
>>         try { ... }
>>         catch (Exception) { ... }
>>     else { ... }
>>   finally { ... }
>>
>> This code is currently legal and binds the "else" clause to the "if"
>> and the "finally" to the first "try". The proposed feature will bind
>> the "else" and the "finally" to the second try and then probably fail
>> to compile because there is no "catch" or "finally" matching the first
>> "try".
>
> Yeah... that's a pain.
>
> How about using different keywords:
>
> try
> {
>     // blah
> }
> /*else*/ catch (nothrow)
> {
>     // on success.
> }
>
>

No. Just no ;)

The more I think about this submission, I feel like the benefits are 
quite slim. The else clause is really simply a disabling of all the 
exception handlers at the end of the function. The uses seem very

There are some funky English problems too.

For example, should it be valid to use "else" without a catch? This 
reads weird:

try { ... }
else { ...}

I think probably the else should be invalid without a valid catch 
clause. Otherwise, you could just use scope(success).

The boolean to indicate an exception was thrown is cumbersome, but not 
horrible. Having the compiler manage the boolean may make this cleaner 
(e.g. finally(bool thrown)), I like it better than the else suggestion.

-Steve