Re: Assertions

Assertions have three defining characteristics: 1) They are (potentially inefficient) checks run in debug/non-production that completely disappear when run in production. 2) When they pass, they produce no side effects. 3) When an assertion fails, which can only ever happen in debug/non-production, the program dies. Each component of this triad interacts with the others to make assertions something different than the other tools in the debugging toolbox, which is why they have value. Talking about catching exceptions thrown by an assertion failure seems very contrary to that, because even if PHP is hardcoded to completely ignore everything between "assert" and ";" when parsing in production, any attempt to catch assertion-related exceptions won't get the same treatment and will still be present in the production code. This can cause a change in behavior, particularly in the case of catching all exceptions, and encourages the generation of side effects (like trying to recover an error) from an assertion test which will no longer be performed when assertions are disabled for production. If you want a concise easy-to-write test that throws an exception if it's not true and runs in production code in catchable way that doesn't abort the app, that is a great idea. But it is not an assertion. It is also already easy to do. Just write: function Expect($shouldBeTrue, $message) { if (!$shouldBeTrue) throw new FMLException($message); } Expect($myObject->internalState == OBJECT_STATE_VALID, "object state is not valid"); Customize as needed with your favorite exception type. Maybe there is some reason why a variant of this should be in the language core, although that's not immediately clear, but it seems really hard to justify redefining the solid and well-understood concept of assertions to do it. Thanks!