[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