On Thu, Oct 17, 2013 at 11:51 AM, Nikita Popov <
[email protected]> wrote:
Nobody is arguing that assertions should be used as a control-flow
structure. It's still most useful to implement them as exceptions. Apart
from being a lot better integrated than fatal errors (in particular they
have such fancy things like stacktraces...) exceptions can also be
gracefully handled where necessary.
If it is useful to handle an assertion, then it wasn't an assertion.
The minute you talk about "handling" assertions they become a control
flow structure and cease to be assertions.
PHPUnit will catch the exception and tell you that an assertion failed, but it will still be able to continue running the rest of the testsuite.
A framework (or front controller in general) can easily catch the exception at the top level and display an appropriate debugging page (rather than doing ugly register_shutdown_function hacks that are necessary to have even remotely graceful handling of fatals).
A deamon or server will be able to process further requests, even if one particular had an assertion failure.
Those are three great examples of how assertions are frequently misused.
There are *many* cases where assertions are not useful. That means
use a different tool in those cases (like an exception), not that
assertions should be made into shorthand for exception throwing.
That functionality is fine to have, just call it something else.
Thanks!
The new implementation doesn't _require_ that you control the flow of execution but _allows_ you to, better than callbacks did.
It is not practical to try and implement assert() as we know it in C, an aborted PHP program is not useful to the user, there is no coredump, there is nothing useful we can do other than pass control of execution back to the program where it is prepared to deal with it ...