[Issue 21443] scope (failure) with a return breaks safety
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Wed Jun 8 01:35:18 UTC 2022
https://issues.dlang.org/show_bug.cgi?id=21443
Steven Schveighoffer <schveiguy at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |safe, spec
CC| |schveiguy at gmail.com
Severity|major |critical
--- Comment #1 from Steven Schveighoffer <schveiguy at gmail.com> ---
I concur. Recently came up on the forums in response to a blog post I made:
https://forum.dlang.org/post/tylpiqohdfqsiiqupfta@forum.dlang.org
Since an Error does not necessarily properly unwind the stack, just returning a
normal error code doesn't reflect the gravity of the situation -- you should
not be allowed to swallow Errors and continue.
My suggestion would be to rewrite the scope(failure) code as:
```d
try {
...
} catch(Error err) {
// return 10; // not allowed
abort("Cannot return from thrown Error");
} catch(Throwable) {
return 10;
}
```
Which would allow code to still compile, but not allow Undefined Behavior.
I would suggest this still happen even inside @system code. If you want to
circumvent, write out the try/catch yourself.
I'd also be OK with Andrej's suggestion (no return inside scope(failure), or
anything like it, such as a goto outside the block).
I should note, the spec specifically allows this, as it forbids returns inside
scope(exit) and scope(success), but purposefully leaves out scope(failure).
--
More information about the Digitalmars-d-bugs
mailing list