Concept proposal: Safely catching error
Steven Schveighoffer via Digitalmars-d
digitalmars-d at puremagic.com
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.
[snip]
>
> 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
(shudder).
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.
-Steve
More information about the Digitalmars-d
mailing list