Concept proposal: Safely catching error

[Olivier FAURE via Digitalmars-d]

On Monday, 5 June 2017 at 10:59:28 UTC, Moritz Maxeiner wrote:
>
> Pragmatic question: How much work do you think this will 
> require?

Good question. I'm no compiler programmer, so I'm not sure what 
the answer is.

I would say "probably a few days at most". The change is fairly 
self-contained, and built around existing concepts (mutability 
and @safety); I think it would mostly be a matter of adding a 
function to the safety checks that tests whether a mutable 
reference to non-local data is used in any try block with 
catch(Error).

Another problem is that non-gc memory allocated in the try block 
would be irreversibly leaked when an Error is thrown (though now 
that I think about it, that would probably count as impure and be 
impossible anyway). Either way, it's not a safety risk and the 
programmer can decide whether leaking memory is worse than 
brutally shutting down for their purpose.

> Because writing a generic wrapper that you can customize the 
> fault behaviour for using DbI requires very little.

Using an array wrapper only covers part of the problem. Users may 
want their server to keep going even if they fail an assertion, 
or want the performance of @nothrow code, or use a library that 
throws RangeError in very rare and hard to pinpoint cases.

Arrays aside, I think there's some use in being able to safely 
recover from (or safely shut down after) the kind of broken 
contracts that throw Errors.