> However I think it is pre mature to vote on as there was (sorry) not explicit discussions about it.
I haven't heard that from anyone else, the RFC is plenty old. > A couple of things are unclear. See the numerous questions in this thread. > I also do not like other things. These don't seem like valid reasons to hold off progress. > zend.assertions: Having a more general debug setting might be a good idea, but is outside of the scope of this RFC. > assert.exceptions: Delay isn't necessary, exceptions are not used by default, and there is plenty of time for Engine Exceptions to make necessary changes. Cheers Joe On Fri, Feb 20, 2015 at 2:55 PM, Crypto Compress < cryptocompr...@googlemail.com> wrote: > 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 >> > >
