Concept proposal: Safely catching error

[Olivier FAURE via Digitalmars-d]

On Monday, 5 June 2017 at 12:51:16 UTC, ag0aep6g wrote:
> On 06/05/2017 11:50 AM, Olivier FAURE wrote:
>> In other words, @safe functions would be allowed to catch 
>> Error after try blocks if the block only mutates data declared 
>> inside of it; the code would look like:
>> 
>>      import vibe.d;
>> 
>>      // ...
>> 
>>      string handleRequestOrError(in HTTPServerRequest req) 
>> @safe {
>>          ServerData myData = createData();
>> 
>>          try {
>>             ...
>>          }
>>          catch (Error) {
>>              throw new SomeException("Oh no, a system error 
>> occured");
>>          }
>>      }
>>
>>      ...
>>
>
> But `myData` is still alive when `catch (Error)` is reached, 
> isn't it?

Good catch; yes, this example would refuse to compile; myData 
needs to be declared in the try block.

> How does `@trusted` fit into this? The premise is that there's 
> a bug somewhere. You can't assume that the bug is in a 
> `@system` function. It can just as well be in a `@trusted` one. 
> And then `@safe` and `pure` mean nothing.

The point of this proposal is that catching Errors should be 
considered @safe under certain conditions; code that catch Errors 
properly would be considered as safe as any other code, which is, 
"as safe as the @trusted code it calls".

I think the issue of @trusted is tangential to this. If you (or 
the writer of a library you use) are using @trusted to cast away 
pureness and then have side effects, you're already risking data 
corruption and undefined behavior, catching Errors or no catching 
Errors.