On Thu, Oct 17, 2013 at 1:33 PM, Nikita Popov <
[email protected]> wrote:
Similarly, showing a friendly debugging page when an assertion fails does
not seem to go against your idea of assertions.
You may be using asserts to test much too complicated concepts.
Assertions are a *very* low-level feature. The classic example of an
assert is to check that expectations are valid in some function that
gets called in a loop 20,000,000 times and takes 6 minutes to run if
you check the conditions and 3 seconds if you don't.
If you are using assert to check that the session data is valid or
that the MySQL connection is valid or something, that's not good. If
there's an error message, it wasn't an assertion. If it's
recoverable, it wasn't an assertion.
It just changes the
presentation form to simplify debugging the cause by specifying additional
information that is known to the framework (but not to the assertion
itself).
Why do we need a new way to throw an exception?
Why do we need to mess up another tool that has a different purpose to do
it?
What's wrong with writing the three-line function one time to get the
behavior you want?
Those questions have a very simple answer: You can't disable code throwing
exceptions ;) Assertions can be disabled.
No, the code that throws "assertion exceptions" can be disabled. The
code that catches them cannot.
The value that assertions provide is the independent error handling
channel. If you do not want the value that assertions provide, don't
use them.
If you want to make that error handling channel more robust and
useful, go nuts, that would be great.
If you want disable-able exception checks that can be skipped based on
a global setting, and for some reason testing the global setting
before testing the condition and throwing the exception is offensive
to you, find a good name for this new feature and propose that.
But please don't screw up existing code for people that use assertions
properly by redefining them as exceptions.
The behavior you're describing is trivial to implement at the user
level, and it's still not clear why it belongs in the language core or
why it needs to alter other, different, existing behavior.
Thanks!
Assertions in PHP are whatever we implement them to be, there isn't really any low level features in PHP, it's a high level programming language where you would not expect to find any.
By default, a failed assertion in PHP results in an E_WARNING being raised, this is not "using assertions properly", this is just generating warnings. Assertions, written originally for PHP4, are currently supported by other user land functions, module globals, callbacks and ini settings. You can only evaluate strings, you cannot use actual expressions, you cannot use anonymous functions.
We are not implementing assert() as it is in C, we are implementing an assert() that is useful in PHP5. One that does not require user land functions, module globals and a bunch of ini settings.
One that does allow you to use expressions, and annonymous functions.
You have been provided very good rationale for the use of exceptions to handle failed assertions, we'd all be grateful if you could stop derailing the conversation.
Cheers
Joe