On 9/28/2014 9:31 PM, "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dl...@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!
