Concept proposal: Safely catching error

[Moritz Maxeiner via Digitalmars-d]

On Monday, 5 June 2017 at 12:01:35 UTC, Olivier FAURE wrote:
> On Monday, 5 June 2017 at 10:59:28 UTC, Moritz Maxeiner wrote:
>>
>> Pragmatic question: How much work do you think this will 
>> require?
>
> 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).

D considers allocating memory as pure[1].

> 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.

Sure, but with regards to long running processes that are 
supposed to handle tens of thousands of requests, leaking memory 
(and continuing to run) will likely eventually end up brutally 
shutting down the process on out of memory errors. But yes, that 
is something that would have to be evaluated on a case by case 
basis.

>
>> 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.

It *replaces* the hard coded assert Errors with flexible attests, 
that can throw whatever you want (or even kill the process 
immediately), you just have to disable the runtimes internal 
bound checks via `-boundscheck=off`.

> Users may want their server to keep going even if they fail an 
> assertion

Normal assertions (other than assert(false)) are not present in 
-release mode, they are purely for debug mode.

> or want the performance of @nothrow code

That's easily doable with the attest approach.

> or use a library that throws RangeError in very rare and hard 
> to pinpoint cases.

Fix the library (or get it fixed if you don't have the code).

>
> 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.

I consider there to be value in allowing users to say "this is 
not a contract, it is a valid use case" (-> wrapper), but a 
broken contract being recoverable violates the entire concept of 
DbC.

[1] https://dlang.org/spec/function.html#pure-functions