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
