This thread on Hacker News terrifies me

[Nick Sabalausky (Abscissa)]

On 09/03/2018 12:46 AM, H. S. Teoh wrote:
> On Sun, Sep 02, 2018 at 09:33:36PM -0700, H. S. Teoh wrote:
> [...]
>> The reason I picked memory corruption is because it's a good
>> illustration of how badly things can go wrong when code that is known to
>> have programming bugs continue running unchecked.
> [...]
> 
> P.S. And memory corruption is also a good illustration of how a logic
> error in one part of the program can cause another completely unrelated
> part of the program to malfunction.  The corruption could have happened
> in your network stack, but it overwrites memory used by your GPU code.
> You cannot simply assume that just because the network module has
> nothing to do with the GPU module, that a GPU code assertion failure
> cannot be caused by a memory corruption in the network module.
> Therefore, you also cannot assume that an assertion in the GPU code can
> be safely ignored, because by definition, the program's logic is flawed,
> and so any assumptions you may have made about it may no longer be true,
> and blindly continuing to run the code means the possibility of actually
> executing a remote exploit instead of the GPU code you thought you were
> about to execute.
> 

Isn't that assuming the parts aren't @safe? ;)

> Anything less is unsafe, because being
> in an invalid state means you cannot predict what the program will do
> when you try to recover it.  Your state graph may look nothing like what
> you thought it should look like, so an action that you thought would
> bring the program into a known state may in fact bring it into a
> different, unknown state, which can exhibit any arbitrary behaviour.

You mean attempting to doing things, like say, generate a stack trace or 
format/display the name of the Error class and a diagnostic message? ;)

Not to say it's all-or-nothing of course, but suppose it IS memory 
corruption and trying to continue WILL cause some bigger problem like 
arbitrary code execution. In that case, won't the standard Error class 
stuff still just trigger that bigger problem, anyway?