Re: Assertions

From: Date: Fri, 18 Oct 2013 06:11:40 +0000
Subject: Re: Assertions
References: 1 2 3 4 5 6 7 8 9 10 11 12 13  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On 10/17/2013 07:06 PM, J David wrote:
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

Thread (36 messages)

« previous php.internals (#69664) next »