Why can't I disable a strict type error?

Why can't I disable a strict type error?

// I am currently using php5.3. // Press php. set in ini (error_reporting = E_ALL | E_STRICT). // Two strict errors are displayed on this page (see the code comment below) // ini_set ("error_reporting", E_ALL ); // write this. only error 2 is allowed to be disabled. // ini_set ("error_reporting", E_NOTICE ); // This operation can only disable error 2. // ini_set ("display_errors", 0); // This operation can only disable error 2. // The problem is: why is this strict error caused by the same name of the subclass and its parent class but different parameters disabled? Class Person {public $ name; public $ age; private function f1 ($ x) {echo "x =" in Person ". $ x ;}} class Teacher extends Person {public $ depart; // Department public function f1 ($ x, $ y) {// The method parameter here is different from the method with the same name as the parent class. // therefore, an exception of strict type (1) echo "x =" in Person ". $ x, ", y = ". $ y ;}$ o1 = new Teacher (); $ o1-> f1 (); $ o1: f1 ); // if the static method is used to call non-static methods, a strict error (No. 2) is reported)

Reply to discussion (solution)

Error_reporting = E_ALL ^ E_STRICT

Error_reporting = E_ALL ^ E_STRICT

Big Bamboo, No.
Originally: E_ALL | E_STRICT is the actual "all errors" message;
E_ALL indicates that strict is not displayed (but all others are displayed );
E_NOTICE indicates that only the notice error is displayed (none of the others are displayed );
Even ini_set ("display_errors", 0) does not display any error information, but the error is still displayed!
My confusion is here: it seems that the strict error cannot be closed.

Can this happen? error_reporting (E_ALL &~ E_STRICT );

Php 5.3 does not check E_STRICT errors by default (php 5.4 and above are checked by default)
Your error_reporting = E_ALL | E_STRICT indicates that you want to check the E_STRICT level error.

Since you want to check for E_STRICT errors, there will be no "off" (you opened it yourself)
Because php does not have the concept of overload, when the subclass method overwrites the parent class method, the number of parameters should be the same to avoid misunderstanding. This is one of the content of the E_STRICT level check.

Note that the syntax check is in the front, and the program runs after
Therefore, even ini_set ("display_errors", 0) cannot block syntax errors!

Manual description 5.4.0 E_STRICT is part of E_ALL
Earlier versions are not displayed unless specified.


// Close all PHP error reports
Error_reporting (0 );

The submitted csdn web page shows 403 again. The IP address is too large to access and crawlers are suspected. It is normal to enter the verification code several times.

Php 5.3 does not check E_STRICT errors by default (php 5.4 and above are checked by default)
Your error_reporting = E_ALL | E_STRICT indicates that you want to check the E_STRICT level error.

Since you want to check for E_STRICT errors, there will be no "off" (you opened it yourself)
Because php does not have the concept of overload, when the subclass method overwrites the parent class method, the number of parameters should be the same to avoid misunderstanding. This is one of the content of the E_STRICT level check.

Note that the syntax check is in the front, and the program runs after
Therefore, even ini_set ("display_errors", 0) cannot block syntax errors!

I mean, I set it to E_ALL | E_STRICT in php. ini, but in the current file, I did the following three tests:
// Ini_set ("error_reporting", E_ALL); // write this and only disable error 2.
// Ini_set ("error_reporting", E_NOTICE); // You can only disable error 2 when writing this message.
// Ini_set ("display_errors", 0); // You can only disable error 2.
That is to say, the E_STRICT error of Line 1 (row 20th) cannot be disabled.
In addition, I have a comparison. The 26th rows are also E_STRICT errors, and any of the three codes will be disabled.

I mean, it is also an E_STRICT error. one can be switched off and the other cannot be switched off.
Does my main building express ambiguity or misunderstanding?

The syntax check question you mentioned. However, this is not a syntax check error. The syntax check error prompt is E_PARSE, which is checked first and then run. The syntax is wrong and does not run at all. But I can run this program and output results in the last line.

STRICT
This is not a syntax check?

E_PARSE is a fatal error, that is, the program is interrupted
E_STRICT is checked according to strict syntax, and the program will not be interrupted when it appears
E_NOTICE is used to check whether the variables are undefined, and does not affect program execution.

Ini_set ('display _ errors ', 'off ');

STRICT
This is not a syntax check?

E_PARSE is a fatal error, that is, the program is interrupted
E_STRICT is checked according to strict syntax, and the program will not be interrupted when it appears
E_NOTICE is used to check whether the variables are undefined, and does not affect program execution.

Thank you for the xuzuning moderator and fdipzone! Especially for moderators.

The suggestions provided by fdipzone are invalid.

Next we will reply to the moderator's reply.

First, we may understand that the "syntax check" is different. The syntax check I understand means that before a program runs, it first checks whether the syntax is "correct", that is, "suitable for running" (or "runable ). This check is performed before running the program. If this type of syntax error is found, the E_PARSE error is directly reported instead of running. For example, a semicolon is missing.

Then, after this step is checked, the program starts to run. During the running process, if some errors occur (this is called a runtime error), an error prompt is displayed, but most errors can be "continued" (although the error prompt is also output ). Currently, I know that two types of errors will "stop running", that is, the E_ERROR you mentioned, and the user-defined error E_USER_ERROR.

We have errors in various situations, such as E_NOTICE, E_WARMING, and E_STRICT, which can continue to run after an error. ini configuration item error_reporting (global impact) or ini_set ('error _ report ',.....) (affects this page) to disable the error message (that is, do not display it ). For example, the last E_STRICT error (row 26th) in my example can be closed. Note: Errors 1 and 2 in my example are all E_STRICT errors, that is, the syntax check errors you mentioned. As you can understand, these two points are indeed "not strict syntax", but please note that you can continue to run the output results here. Error 1 indicates that the parameter of the f1 method of the subclass is different from that of the parent class, but the program is not allowed to run. Error 2 indicates that a non-static method is called in a static way, and the program is not allowed to run. Strictly speaking, both of them are "syntax errors" (according to your understanding), but the result is that one can be closed and the other cannot be closed.

My problem is that the "types" of these two errors are the same (you can test and view the results), but the last one can be closed (not displayed), and the previous one cannot be closed. Why? You can also ask from another angle: how to disable the previous error prompt?

How to disable the previous error prompt?
1. use phpinfo () to check which php. ini is currently working (multiple can be found, but one is actually loaded by the system)
2. change error_reporting = E_ALL | E_STRICT:
Error_reporting = E_ALL &~ E_DEPRECATED &~ E_STRICT

How to disable the previous error prompt?
1. use phpinfo () to check which php. ini is currently working (multiple can be found, but one is actually loaded by the system)
2. change error_reporting = E_ALL | E_STRICT:
Error_reporting = E_ALL &~ E_DEPRECATED &~ E_STRICT

1. the php. ini file is correct.
2. You still cannot provide this method.

Why is it so stubborn?
E_STRICT will not terminate the running of the program!

The first strict type error is reported in the syntax analysis phase.
The second strict type error is reported during the running stage.

How to disable the previous error prompt?
1. use phpinfo () to check which php. ini is currently working (multiple can be found, but one is actually loaded by the system)
2. change error_reporting = E_ALL | E_STRICT:
Error_reporting = E_ALL &~ E_DEPRECATED &~ E_STRICT

1. the php. ini file is correct.
2. You still cannot provide this method.

Have you used phpinfo () to check the location of php. ini? maybe you didn't use it.

How to disable the previous error prompt?
1. use phpinfo () to check which php. ini is currently working (multiple can be found, but one is actually loaded by the system)
2. change error_reporting = E_ALL | E_STRICT:
Error_reporting = E_ALL &~ E_DEPRECATED &~ E_STRICT

1. the php. ini file is correct.
2. You still cannot provide this method.

Have you used phpinfo () to check the location of php. ini? maybe you didn't use it.

Sorry. My reply yesterday was too hasty. I meant to disable error 2 by using ini_set ("error_reporting", E_ALL) (or changing E_ALL to another value) in the script code of the PHP file, but cannot close error 1, so I asked for help (ask), so I didn't test how to change php. ini.

Test today and close it. In fact, the settings that I have provided will take effect as long as they are set in php. ini.

However, my problem still exists, that is, the E_STRICT error is the same. why do I use ini_set ("error_reporting", E_ALL) (or change E_ALL to another value) in the example I gave ), can I close on the 2nd, but cannot I close on the 1st? For this question, please refer to my subsequent post to the moderator.

Why is it so stubborn?
E_STRICT will not terminate the running of the program!

The first strict type error is reported in the syntax analysis phase.
The second strict type error is reported during the running stage.

Okay, I think so. You are serious and responsible. I have a chance to talk to Jiang Tao.

As you said, although all errors of the E_STRICT type are reported, the first error is reported in the syntax analysis stage and the second error is reported in the running stage. If this is the case, as we usually understand, using ini_set ("error_reporting", XXX) can close some types of errors as long as the appropriate value of XXX is set.

Therefore, can I set the same type of error message in the script using ini_set? can Some be disabled or some be disabled? How can we close it, and how can we not close it? Where can I find this knowledge?

In addition, it is also a "syntax check" error. some errors make the program unable to be executed, some report E_PARSE errors, and some allow the program to be executed, as you said, but report an E_STRICT error. Even if you say that E_PARSE is a fatal syntax error, and E_STRICT can continue to run, how can we distinguish the two ??? Of course, this may not be a problem.

Also, for errors similar to my suggestion. the INI file can be used to close the prompt, but the script cannot be used to close the prompt. but in other cases, the error prompt seems to be consistent on both sides. what is the explanation?

Finally, I am stubborn. you have the ability to answer me.

?? In the end, I hope you understand the joke, at least don't mind.

You will know when you do a test. it's not all about finding a theoretical basis.

Echo ini_get ('error _ Report '),'
'; // Check the value error_reporting (E_ALL ^ E_STRICT) defined in php. ini; // disable the echo ini_get ('error _ Report '),'
'; // Check the modified class Person {public $ name; public $ age; private function f1 ($ x) {echo "Person x = ". $ x ;}} class Teacher extends Person {public $ depart; // Department public function f1 ($ x, $ y) {// The method parameter here is different from the method with the same name as the parent class. // therefore, an exception of strict type (1) echo "x =" in Person ". $ x, ", y = ". $ y ;}$ o1 = new Teacher (); $ o1-> f1 (); $ o1: f1 (); // if the E_STRICT check is not disabled, A strict error (No. 2) is reported when a non-static method is called in static mode)

Strict Standards: Declaration of Teacher: f1 () shocould be compatible with Person: f1 ($ x) in D: \ AMP \ web \ ide_tmp.php on line 193276730719Person x = 1, in y = 2Person, x = 3, y = 4

Although the E_STRICT check is disabled in the program, the error 1 still appears.
Apparently, the error check for the class definition is prior to error_reporting (E_ALL ^ E_STRICT );

You will know when you do a test. it's not all about finding a theoretical basis.

Although the E_STRICT check is disabled in the program, the error 1 still appears.
Apparently, the error check for the class definition is prior to error_reporting (E_ALL ^ E_STRICT );

Well, I have already accepted your suggestion in the previous post. as for testing, I naturally want to do it. it was because I had encountered such a situation and hoped to get some explanations or solutions.

Now that you have already said, "it's not all about finding a theoretical basis." It shows that the three last questions I have raised do not need to be resolved, right?

Okay. The world is so imperfect that I have no right to ask for what I can't do :)