Am 20.02.2015 um 15:09 schrieb Nikita Popov:
On Fri, Feb 20, 2015 at 3:02 PM, Crypto Compress
<cryptocompr...@googlemail.com <mailto:cryptocompr...@googlemail.com>>
wrote:
AssertionExceptions are not intended to be caught, they are
intended to be seen, in a specific environment.
Joe, your argumentation is around how (not) to use exceptions. I
can see your point and it's valid.
My point is about not to implement exceptions at all.
If exceptions are not intended to be caught, they don't need to be
thrown (even if the context is different).
If exceptions are not thrown and not caught, we can use "error" in
dev and some easing severity (warning, zero cost nothing) in prod.
Freely adapted from Murphy: If assertion exception can be catched,
it will be even in production.
The point behind AssertionException is that
a) It will leave the scope where with the failed assertion
immediately. A warning would continue running the code, even though
some precondition is violated, which doesn't make sense.
Assumed context is wrong here.
- exception in development: error
- no exception in production: warning, zero cost nothing
Rephrased: A zero-cost non-existing exception would continue running the
code, ...
In a previous email you brought up the point if or not derive
AssertionEx from Exception. I argue that all child exception MUST BE
derived from Exception. Any exception to this is not an Exception. (my
english is too limited to explain this, sorry)
b) It can still be gracefully handled (unlike a fatal error). E.g. the
unit testing framework can catch it, so you can continue running all
your tests even if one causes an assertion failure.
Unit test frameworks do this already. No change here.
When Joe says "not intended to be caught" this is referring to
"normal" code. Catching them at the top-level still makes sense, e.g.
for the unit testing case mentioned or even just to print a nice error
message with extra information. Using an exception instead of a fatal
error also means that things like "finally" will still run, so your
code can still release locks etc even if an assertion failure occurred.
In production this will never happen. We go round in circles here. I am
aware of you preference on "exceptions everywhere".
Nikita
