찾다
백엔드 개발PHP 튜토리얼一个strict类型的错误为什么“关”不掉?

//我当前是php5.3版//按php.ini中的设置(error_reporting = E_ALL | E_STRICT),//本页会显示2个strict类型的错误(见后面代码注释)//ini_set("error_reporting",E_ALL);		//写这个,只能关闭2号错误提示//ini_set("error_reporting",E_NOTICE);	//写这个也只能关闭2号错误提示//ini_set("display_errors", 0);			//这个还是只能关闭2号错误提示//问题就是:为什么子类跟父类同名但不同参的这个strict错误,为什么关不掉? class Person{	public $name;	public $age;	private function f1($x){		echo "Person中x = " . $x;	}}class Teacher extends Person{	public $depart;	//所属部门	public function f1($x,$y){	//这里方法参数跟父类同名方法不同,								//因此报一个strict类型的错(1号)		echo "Person中x = " . $x , ", y=" . $y ;	}}$o1 = new Teacher();$o1->f1(1,2);$o1::f1(3,4);	//这里使用静态方式调用非静态方法,也报一个strict错(2号)


回复讨论(解决方案)

error_reporting = E_ALL ^ E_STRICT

error_reporting = E_ALL ^ E_STRICT



大斑竹,不行啊。
本来这个:E_ALL | E_STRICT是现实“所有错误”信息;
而E_ALL 已经表示不显示strict错误了(但其他都显示);
而E_NOTICE更表示只显示notice错误(其他的都不显示);
甚至ini_set("display_errors", 0)是不显示任何错误信息,但那个错误还是显示呢!
我的困惑就在这里:那个strict错误似乎怎么样都关不掉呢。

这样可以吗   error_reporting (E_ALL  &  ~ E_STRICT);

php 5.3 默认是不检查 E_STRICT 级别错误的(php 5.4 及以上是默认检查的)
你 error_reporting = E_ALL | E_STRICT 就表示要检查 E_STRICT 级别错误

既然你要检查 E_STRICT 级别错误,那就不存在什么“关”不掉了(是你自己打开的)
因为 php 没有重载的概念,所以当子类方法覆盖父类方法时,参数数量应该一样,以免产生误解。这就是 E_STRICT 级别检查的内容之一

需要注意的是:语法检查在前,程序运行在后
所以即使 ini_set("display_errors", 0) 也不能屏蔽掉语法错误!

手册说 5.4.0 E_STRICT 成为 E_ALL 的一部分
之前的版本除非指定要不然不会显示的。


// 关闭所有PHP错误报告
error_reporting(0);

刚才提交csdn网页又有显示403,ip地址访问过多,怀疑爬虫。输了好几遍验证码才正常。

php 5.3 默认是不检查 E_STRICT 级别错误的(php 5.4 及以上是默认检查的)
你 error_reporting = E_ALL | E_STRICT 就表示要检查 E_STRICT 级别错误

既然你要检查 E_STRICT 级别错误,那就不存在什么“关”不掉了(是你自己打开的)
因为 php 没有重载的概念,所以当子类方法覆盖父类方法时,参数数量应该一样,以免产生误解。这就是 E_STRICT 级别检查的内容之一

需要注意的是:语法检查在前,程序运行在后
所以即使 ini_set("display_errors", 0) 也不能屏蔽掉语法错误!



我是说我php.ini中设置为 E_ALL | E_STRICT,但是在当前文件中,我是做了如下3种情况的的测试啊:
//ini_set("error_reporting",E_ALL);        //写这个,只能关闭2号错误提示
//ini_set("error_reporting",E_NOTICE);    //写这个也只能关闭2号错误提示
//ini_set("display_errors", 0);            //这个还是只能关闭2号错误提示
即都关闭不掉1号(第20行)的E_STRICT错误。
而且我有对比的,第26行的同样是E_STRICT错误,这3个代码任意一个都会关闭掉。

我的意思是,同样是E_STRICT错误,一个能关掉,一个怎么也关不掉。
我主楼的表达难道给人歧义或误解么?

你说的语法检查性问题。但我这不是语法检查错误啊。语法检查错误提示是E_PARSE,确实是先检查,后运行。语法有错,根本不运行。但我这个程序是能运行的,最后一行都能输出结果。

STRICT 中文释义 严格的
这不是语法检查是什么?

E_PARSE 检查的是致命错误,即出现了程序就中断
E_STRICT 是按严格的语法进行检查,出现了并不会中断程序
E_NOTICE 是检查变量是否未定义就使用,也不会影响程序的执行

ini_set('display_errors','off');

STRICT 中文释义 严格的
这不是语法检查是什么?

E_PARSE 检查的是致命错误,即出现了程序就中断
E_STRICT 是按严格的语法进行检查,出现了并不会中断程序
E_NOTICE 是检查变量是否未定义就使用,也不会影响程序的执行



谢谢xuzuning版主和fdipzone!特别是版主的不辞辛苦。

fdipzone提供的建议不行。

下面来在专门转对版主的回复进行答复。

首先,也许我们俩理解的“语法检查”不一样。我理解的语法检查是指,程序在运行之前,先检查语法是否“正确”,即是否“适合运行”(或是否可运行)。这种检查是在运行程序之前的。如果发现这类语法错误,则不会进行任何运行,而是直接报E_PARSE错误。比如最简单也最常见的就是漏了一个分号。

然后,这一步检查过之后,程序就开始运行了。在运行过程中,如果发生了某些错误(这叫运行时错误),则相应会给出出错提示,但大多数错误都可以“继续运行”下去(虽然错误提示也一并输出)。 目前我知道的就2种错误是会“停止运行”的,那就是你提到的E_ERROR, 还有就是用户自定义错误E_USER_ERROR。

我们有多种情况下的错误,比如E_NOTICE, E_WARMING, 包括E_STRICT,都会在出错后继续运行,且可以通过php.ini配置项error_reporting(影响全局)或ini_set('error_reporting', .....)(影响本页)来设置将错误提示信息关闭(就是不显示)。如我例子中的后一个E_STRICT错误(第26行),都是可以关闭的。注意,我例子上的1号错误和2号错误,都是E_STRICT类型错误,也就是你说的语法检查的错误。如你理解的,这两个地方确实是“不严格的语法”,但请注意,这里两个地方都可以继续运行输出结果。1号错误是子类的f1方法的参数跟父类不同,但并没有让程序不能运行。2号错误是使用了静态的方式调用了一个非静态方法,也没有让程序不能运行。严格说来这两个都是“语法错误”(按你的理解),但结果是一个能关闭,一个不能关闭。

我的问题就是,这2个错误的“类型”是一样的(你可以测试,看结果),但后一个可以关闭(不显示),前一个关闭不了。为什么?或者换个角度来问:怎么关闭前一个错误提示?

怎么关闭前一个错误提示?
1、用phpinfo()看下,现在起作用的是哪个 php.ini  (能找到多个,但有一个是系统真正加载的)
2、把error_reporting= E_ALL | E_STRICT  改为:
         error_reporting=E_ALL & ~E_DEPRECATED & ~E_STRICT

怎么关闭前一个错误提示?
1、用phpinfo()看下,现在起作用的是哪个 php.ini  (能找到多个,但有一个是系统真正加载的)
2、把error_reporting= E_ALL | E_STRICT  改为:
         error_reporting=E_ALL & ~E_DEPRECATED & ~E_STRICT


1、php.ini文件没问题。 
2、你提供的这个方法还是不行啊。

怎么这么拗呢?
E_STRICT 不会终止程序的运行!

第一个 strict 类型错是在语法分析阶段报出的
第二个 strict类型错是在运行阶段报出的


怎么关闭前一个错误提示?
1、用phpinfo()看下,现在起作用的是哪个 php.ini  (能找到多个,但有一个是系统真正加载的)
2、把error_reporting= E_ALL | E_STRICT  改为:
         error_reporting=E_ALL & ~E_DEPRECATED & ~E_STRICT


1、php.ini文件没问题。 
2、你提供的这个方法还是不行啊。


你用phpinfo()核实php.ini的位置了吗,有可能你改的不是你在用的。



怎么关闭前一个错误提示?
1、用phpinfo()看下,现在起作用的是哪个 php.ini  (能找到多个,但有一个是系统真正加载的)
2、把error_reporting= E_ALL | E_STRICT  改为:
         error_reporting=E_ALL & ~E_DEPRECATED & ~E_STRICT


1、php.ini文件没问题。 
2、你提供的这个方法还是不行啊。


你用phpinfo()核实php.ini的位置了吗,有可能你改的不是你在用的。

抱歉。我昨天的回复过于草率。我本意是指在php文件的脚本代码中使用ini_set("error_reporting",E_ALL) (或把E_ALL改为其他值)的方式,能关闭2号错误,却不能关闭1号错误,因此而求助(提问),因此没测试真正去改php.ini。

今天测试,确实能关闭。实际上,则我自己给出的那几条设置值,只要在php.ini中设置,也都能生效。

但我的问题依然存在,那就是:同样是E_STRICT错误,为什么我给的例子中,使用ini_set("error_reporting",E_ALL) (或把E_ALL改为其他值),2号能关闭,而1号不能关闭?有关此问题,请再看我后续回复版主的帖子。

怎么这么拗呢?
E_STRICT 不会终止程序的运行!

第一个 strict 类型错是在语法分析阶段报出的
第二个 strict类型错是在运行阶段报出的



好吧,算我拗,我也认。你的认真,负责,我有机会一定会跟蒋涛说说的。

也许就是如你所说的,虽然都是E_STRICT类型的错误,但第一个是在语法分析阶段报出的,第二个是运行阶段报出的。那么如果这样的话,就跟我们通常理解的,使用ini_set("error_reporting",XXX),只要设置XXX的合适值就可以关闭某些类型的错误, 有出入了。

因此,是否可以这样说,同样类型的错误提示信息,使用ini_set在脚本中设置,有的能关闭,有的不能关闭?那具体又是,怎么样的能关闭,怎么样的不能关闭呢?这个知识在哪里能查到?

另外,同样是“语法检查”错误,有的是让程序无法执行,报E_PARSE错误,有的是能让程序执行,如你所说的,但报E_STRICT错误。就算按你说的,E_PARSE是致命语法错误,而E_STRICT能继续运行,则又如何区分这两者呢???当然,或许这已经不算什么问题了。

还有,对于类似我提出的这个错误,在php.ini文件中能关闭提示,而在脚本中不能关闭,但其他情况的错误提示,似乎两边都有一致性,则又做何解释?

最后,我就是拗,有本事你答我呀

??最后的最后,我的玩笑希望你懂,至少不介意。

你做个测试就知道了,并不是什么都要找到理论依据的

echo ini_get('error_reporting'), '<br>'; //看看 php.ini 中定义的值error_reporting(E_ALL ^ E_STRICT); //关闭掉 E_STRICT 级别错误检查echo ini_get('error_reporting'), '<br>'; //再看看修改后的值class Person{    public $name;    public $age;    private function f1($x){        echo "Person中x = " . $x;    }}class Teacher extends Person{    public $depart;    //所属部门    public function f1($x,$y){    //这里方法参数跟父类同名方法不同,                                //因此报一个strict类型的错(1号)        echo "Person中x = " . $x , ", y=" . $y ;    }}$o1 = new Teacher();$o1->f1(1,2);$o1::f1(3,4);    //如果没有关闭 E_STRICT 检查,这里使用静态方式调用非静态方法,也报一个strict错(2号)
Strict Standards: Declaration of Teacher::f1() should be compatible with Person::f1($x) in D:\AMP\web\ide_tmp.php on line 193276730719Person中x = 1, y=2Person中x = 3, y=4

虽然在程序中关闭了 E_STRICT 检查,但是 1号 错误依然出现
显然对于类定义的错误检查是先于 error_reporting(E_ALL ^ E_STRICT); 进行的

你做个测试就知道了,并不是什么都要找到理论依据的

虽然在程序中关闭了 E_STRICT 检查,但是 1号 错误依然出现
显然对于类定义的错误检查是先于 error_reporting(E_ALL ^ E_STRICT); 进行的



嗯,我前一贴已经认可了你的说法,至于测试,我自然是要做,而且本来就是因为自己遇到了这样的情形,希望得到一定的解释或解决而已。

那既然你已经说了“并不是什么都要找到理论依据的”,就说明我最后提出的3个问题,就没有必要去纠结了,是么?

好吧。世界如此不完美,我没有权利自己做不到的事情,去要求这个世界:)
성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
11 최고의 PHP URL 쇼트너 스크립트 (무료 및 프리미엄)11 최고의 PHP URL 쇼트너 스크립트 (무료 및 프리미엄)Mar 03, 2025 am 10:49 AM

종종 키워드와 추적 매개 변수로 혼란스러워하는 긴 URL은 방문자를 방해 할 수 있습니다. URL 단축 스크립트는 솔루션을 제공하여 소셜 미디어 및 기타 플랫폼에 이상적인 간결한 링크를 만듭니다. 이 스크립트는 개별 웹 사이트 a에 유용합니다

Instagram API 소개Instagram API 소개Mar 02, 2025 am 09:32 AM

Instagram은 2012 년 Facebook에서 유명한 인수에 이어 타사 사용을 위해 두 개의 API 세트를 채택했습니다. Instagram Graph API 및 Instagram Basic Display API입니다. 개발자는

Laravel의 플래시 세션 데이터로 작업합니다Laravel의 플래시 세션 데이터로 작업합니다Mar 12, 2025 pm 05:08 PM

Laravel은 직관적 인 플래시 방법을 사용하여 임시 세션 데이터 처리를 단순화합니다. 응용 프로그램에 간단한 메시지, 경고 또는 알림을 표시하는 데 적합합니다. 데이터는 기본적으로 후속 요청에만 지속됩니다. $ 요청-

Laravel Back End : Part 2, React가있는 React 앱 구축Laravel Back End : Part 2, React가있는 React 앱 구축Mar 04, 2025 am 09:33 AM

이것은 Laravel 백엔드가있는 React Application을 구축하는 데있어 시리즈의 두 번째이자 마지막 부분입니다. 이 시리즈의 첫 번째 부분에서는 기본 제품 목록 응용 프로그램을 위해 Laravel을 사용하여 편안한 API를 만들었습니다. 이 튜토리얼에서는 Dev가 될 것입니다

Laravel 테스트에서 단순화 된 HTTP 응답 조롱Laravel 테스트에서 단순화 된 HTTP 응답 조롱Mar 12, 2025 pm 05:09 PM

Laravel은 간결한 HTTP 응답 시뮬레이션 구문을 제공하여 HTTP 상호 작용 테스트를 단순화합니다. 이 접근법은 테스트 시뮬레이션을보다 직관적으로 만들면서 코드 중복성을 크게 줄입니다. 기본 구현은 다양한 응답 유형 단축키를 제공합니다. Illuminate \ support \ Facades \ http를 사용하십시오. http :: 가짜 ([ 'google.com'=> ​​'Hello World', 'github.com'=> ​​[ 'foo'=> 'bar'], 'forge.laravel.com'=>

PHP의 컬 : REST API에서 PHP Curl Extension 사용 방법PHP의 컬 : REST API에서 PHP Curl Extension 사용 방법Mar 14, 2025 am 11:42 AM

PHP 클라이언트 URL (CURL) 확장자는 개발자를위한 강력한 도구이며 원격 서버 및 REST API와의 원활한 상호 작용을 가능하게합니다. PHP CURL은 존경받는 다중 프로모토콜 파일 전송 라이브러리 인 Libcurl을 활용하여 효율적인 execu를 용이하게합니다.

Codecanyon에서 12 개의 최고의 PHP 채팅 스크립트Codecanyon에서 12 개의 최고의 PHP 채팅 스크립트Mar 13, 2025 pm 12:08 PM

고객의 가장 긴급한 문제에 실시간 인스턴트 솔루션을 제공하고 싶습니까? 라이브 채팅을 통해 고객과 실시간 대화를 나누고 문제를 즉시 해결할 수 있습니다. 그것은 당신이 당신의 관습에 더 빠른 서비스를 제공 할 수 있도록합니다.

2025 PHP 상황 조사 발표2025 PHP 상황 조사 발표Mar 03, 2025 pm 04:20 PM

2025 PHP Landscape Survey는 현재 PHP 개발 동향을 조사합니다. 개발자와 비즈니스에 대한 통찰력을 제공하는 프레임 워크 사용, 배포 방법 및 과제를 탐색합니다. 이 조사는 현대 PHP Versio의 성장을 예상합니다

See all articles

핫 AI 도구

Undresser.AI Undress

Undresser.AI Undress

사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover

AI Clothes Remover

사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool

Undress AI Tool

무료로 이미지를 벗다

Clothoff.io

Clothoff.io

AI 옷 제거제

AI Hentai Generator

AI Hentai Generator

AI Hentai를 무료로 생성하십시오.

뜨거운 도구

DVWA

DVWA

DVWA(Damn Vulnerable Web App)는 매우 취약한 PHP/MySQL 웹 애플리케이션입니다. 주요 목표는 보안 전문가가 법적 환경에서 자신의 기술과 도구를 테스트하고, 웹 개발자가 웹 응용 프로그램 보안 프로세스를 더 잘 이해할 수 있도록 돕고, 교사/학생이 교실 환경 웹 응용 프로그램에서 가르치고 배울 수 있도록 돕는 것입니다. 보안. DVWA의 목표는 다양한 난이도의 간단하고 간단한 인터페이스를 통해 가장 일반적인 웹 취약점 중 일부를 연습하는 것입니다. 이 소프트웨어는

PhpStorm 맥 버전

PhpStorm 맥 버전

최신(2018.2.1) 전문 PHP 통합 개발 도구

SublimeText3 Mac 버전

SublimeText3 Mac 버전

신 수준의 코드 편집 소프트웨어(SublimeText3)

MinGW - Windows용 미니멀리스트 GNU

MinGW - Windows용 미니멀리스트 GNU

이 프로젝트는 osdn.net/projects/mingw로 마이그레이션되는 중입니다. 계속해서 그곳에서 우리를 팔로우할 수 있습니다. MinGW: GCC(GNU Compiler Collection)의 기본 Windows 포트로, 기본 Windows 애플리케이션을 구축하기 위한 무료 배포 가능 가져오기 라이브러리 및 헤더 파일로 C99 기능을 지원하는 MSVC 런타임에 대한 확장이 포함되어 있습니다. 모든 MinGW 소프트웨어는 64비트 Windows 플랫폼에서 실행될 수 있습니다.

ZendStudio 13.5.1 맥

ZendStudio 13.5.1 맥

강력한 PHP 통합 개발 환경