https://issues.dlang.org/show_bug.cgi?id=21443
Steven Schveighoffer <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |safe, spec CC| |[email protected] Severity|major |critical --- Comment #1 from Steven Schveighoffer <[email protected]> --- I concur. Recently came up on the forums in response to a blog post I made: https://forum.dlang.org/post/[email protected] 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). --
