On Fri, Feb 20, 2015 at 3:02 PM, Crypto Compress < 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. 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. 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. Nikita
