Concept proposal: Safely catching error

Olivier FAURE via Digitalmars-d digitalmars-d at puremagic.com
Wed Jun 7 08:35:56 PDT 2017


On Monday, 5 June 2017 at 12:59:11 UTC, Moritz Maxeiner wrote:
> On Monday, 5 June 2017 at 12:01:35 UTC, Olivier FAURE wrote:
>> 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].
>
> ...
>
> 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.

Note that in the case you describe, the alternative is either 
"Brutally shutdown right now", or "Throwaway some data, 
potentially some memory as well, and maybe brutally shut down 
later if that happens too often". (although in the second case, 
there is also the trade-off that the leaking program "steals" 
memory from the other routines running on the same computer)

Anyway, I don't think this would happen. Most forms of memory 
allocations are impure, and wouldn't be allowed in a try {} 
catch(Error) block; C's malloc() is pure, but C's free() isn't, 
so the thrown Error wouldn't be skipping over any calls to 
free(). Memory allocated by the GC would be reclaimed once the 
Error is caught and the data thrown away.

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

I half-agree. There *should not* be way to say "Okay, the 
contract is broken, but let's keep going anyway".

There *should* be a way to say "okay, the contract is broken, 
let's get rid of all data associated with it, log an error 
message to explain what went wrong, then kill *the specific 
thread/process/task* and let the others keep going".

The goal isn't to ignore or bypass Errors, it's to 
compartmentalize the damage.


More information about the Digitalmars-d mailing list