Program logic bugs vs input/environmental errors

[Walter Bright via Digitalmars-d]

On 9/28/2014 9:31 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang at gmail.com>" wrote:
> 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.

Lots of bad practices are commonplace.


> 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.

You're claiming to know that a program in an unknown and unanticipated state is 
really in a known state. It isn't.


> 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.

Are you really suggesting that asserts should be replaced by thrown exceptions? 
I suspect we have little common ground here.


> 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.

A vast assumption here that you know in advance what bugs you're going to have 
and what causes them.


> 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.

You're using exceptions as a program bug reporting mechanism. Whoa camel, indeed!