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.
