Concept proposal: Safely catching error

Moritz Maxeiner via Digitalmars-d digitalmars-d at
Wed Jun 7 09:05:13 PDT 2017

On Wednesday, 7 June 2017 at 15:35:56 UTC, Olivier FAURE wrote:
> On Monday, 5 June 2017 at 12:59:11 UTC, Moritz Maxeiner wrote:
> Anyway, I don't think this would happen. Most forms of memory 
> allocations are impure,

Not how pure is currently defined in D, see the referred spec; 
allocating memory is considered pure (even if it is impure with 
the theoretical pure definition).
This is something that would need to be changed in the spec.

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

The problem is that in current operating systems the finest 
scope/context of computation you can (safely) kill / 
compartmentalize the damage in in order to allow the rest of the 
system to proceed is a process (-> process isolation).
Anything finer than that (threads, fibers, etc.) may or may not 
work in a particular use case, but you can't guarantee/proof that 
it works in the majority of use cases (which is what the runtime 
would have to be able to do if we were to allow that behaviour as 
the default).
Compartmentalizing like this is your job as the programmer imho, 
not the job of the runtime.

More information about the Digitalmars-d mailing list