On Thu, Oct 17, 2013 at 1:20 PM, Joe Watkins <[email protected]> wrote:
> The new implementation doesn't _require_ that you control the flow of
> execution but _allows_ you to, better than callbacks did.
Does this new exception derive from Exception? (Hint: It does.)
Is it caught by set_exception_handler() ?
Then it requires you to control the flow of execution.
> 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,
Assertions do not abort programs in front of the user, because they
are turned off. They abort programs in front of the developer.
> 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 …
The suggestion to have assertion failure generate an exception-like
stack trace was an excellent one. The "PHP core dump" idea was pretty
cool too, though one can only imagine how much work that would be.
Beyond that, you are essentially arguing to remove assert() entirely,
since the functionality you describe already exists. It's called
throwing exceptions and the presented rationale for redefining
language features to create new ways to throw them is unsatisfactory
to me.
It's hard not to notice that the fundamental question keeps getting
avoided: if this is the behavior you want, what's wrong with throwing
an exception? What new capability is being created that justifies
changing the language and sacrificing the old capability?
Thanks!