Concept proposal: Safely catching error

[ag0aep6g via Digitalmars-d]

On 06/05/2017 11:50 AM, Olivier FAURE wrote:
> - But memory corruption is super bad, if a proved error *might* be 
> caused by memory corruption then we must absolutely throw the 
> potentially corrupted data away without using it.
> 
> - Besides, even without memory corruption, the same argument applies to 
> broken invariants; if we have data that breaks invariants, we need to 
> throw it away, and use it as little as possible.
> 
[...]
> 
> 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.
> 
> In other words, @safe functions would be allowed to catch Error after 
> try blocks if the block only mutates data declared inside of it; the 
> code would look like:
> 
>      import vibe.d;
> 
>      // ...
> 
>      string handleRequestOrError(in HTTPServerRequest req) @safe {
>          ServerData myData = createData();
> 
>          try {
>              // both doSomethingWithData and mutateMyData are @pure
> 
>              doSomethingWithData(req, myData);
>              mutateMyData(myData);
> 
>              return myData.toString;
>          }
>          catch (Error) {
>              throw new SomeException("Oh no, a system error occured");
>          }
>      }
> 
>      void handleRequest(HTTPServerRequest req,
>                         HTTPServerResponse res) @safe
>      {
>          try {
>              res.writeBody(handleRequestOrError(req), "text/plain");
>          }
>          catch (SomeException) {
>              // Handle exception
>          }
>      }
> 
> The point is, this is safe even when doSomethingWithData breaks an 
> invariant or mutateMyData corrupts myData, because the compiler 
> guarantees that the only data affected WILL be thrown away or otherwise 
> unaccessible by the time catch(Error) is reached.

But `myData` is still alive when `catch (Error)` is reached, isn't it?

[...]
> 
> What do you think? Does the idea have merit? Should I make it into a DIP?

How does `@trusted` fit into this? The premise is that there's a bug 
somewhere. You can't assume that the bug is in a `@system` function. It 
can just as well be in a `@trusted` one. And then `@safe` and `pure` 
mean nothing.