Concept proposal: Safely catching error

Steven Schveighoffer via Digitalmars-d digitalmars-d at
Mon Jun 5 07:05:27 PDT 2017

On 6/5/17 5:50 AM, Olivier FAURE wrote:
> I recently skimmed the "Bad array indexing is considered deadly" thread,
> which discusses the "array OOB throws Error, which throws the whole
> program away" problem.
> My proposal for solving these problems would be to explicitly allow to
> catch Errors in @safe code IF the try block from which the Error is
> caught is perfectly pure.

I don't think this will work. Only throwing Error makes a function 
nothrow. A nothrow function may not properly clean up the stack while 
unwinding. Not because the stack unwinding code skips over it, but 
because the compiler knows nothing can throw, and so doesn't include the 
cleanup code.

So this means, regardless of whether you catch an Error or not, the 
program may be in a state that is not recoverable.

Not to mention that only doing this for pure code eliminates usages that 
sparked the original discussion, as my code communicates with a 
database, and that wouldn't be allowed in pure code.

The only possible language change I can think of here, is to have a 
third kind of Throwable type. Call it SafeError. A SafeError would be 
only catchable in @system or @trusted code.

This means that @safe code would have to terminate, but any wrapping 
code that is calling the @safe code (such as the vibe.d framework), 
could catch it and properly handle the error, knowing that everything 
was properly cleaned up, and knowing that because we are in @safe code, 
there hasn't been a memory corruption (right?).

Throwing a SafeError prevents a function from being marked nothrow. I 
can't see a way around this, unless we came up with another attribute 

Then we can change the compiler (runtime?) to throwing SafeRangeError 
instead of RangeError inside @safe code.

All of this, I'm not proposing to do, because I don't see it being 
accepted. Creating a new array type which is used in my code will work, 
and avoids all the hassle of navigating the DIP system.


More information about the Digitalmars-d mailing list