Program logic bugs vs input/environmental errors

[via Digitalmars-d]

On Sunday, 28 September 2014 at 22:59:46 UTC, Walter Bright wrote:
> If anyone is writing code that throws an Exception with 
> "internal error", then they are MISUSING exceptions to throw on 
> logic bugs. I've been arguing this all along.

Nothing wrong with it. Quite common and useful for a non-critical 
web service to log the exception, then re-throw something like 
"internal error",  catch the internal error at the root and 
returning the appropriate 5xx HTTP response, then keep going.

You are arguing as if it is impossible to know whether the logic 
error is local to the handler, or not, with a reasonable 
probability. "Division by zero" is usually not a big deal, but it 
is a logic error. No need to shut down the service.

> I'm not suggesting that Exceptions are to be thrown on 
> programmer screwups - I suggest the OPPOSITE.

It is impossible to verify what the source is. It might be a bug 
in a boolean expression leading to a throw when the system is ok.

assert()s should also not be left in production code. They are 
not for catching runtime errors, but for testing at the expense 
of performance.

Uncaught exceptions should be re-thrown higher up in the call 
chain to a different error level based on the possible impact on 
the system. Getting an unexpected mismatch exception in a 
form-validator is not a big deal. Getting out-of-bounds error in 
main storage is a big deal. Whether it is a big deal can only be 
decided at the higher level.

It is no doubt useful to be able to obtain a stack trace so that 
you can log it when an exception turns out to fall into the "big 
deal" category and therefore should be re-thrown as a critical 
failture. The deciding factor should be performance.