PHP의 오류 처리는 비교적 복잡합니다. 이 글에서는 PHP의 오류 메커니즘을 더 쉽게 이해할 수 있도록 PHP의 오류와 관련된 모든 중요한 지식 사항을 설명합니다.
이전에 php 오류에 대한 기본 지식을 숙지하세요
미리 정의된 상수
런타임 구성
예외
오류 처리 기능
모든 PHP 오류 유형을 정의합니다. 각 상수는 정수 값입니다. 해당 기능은
위의 값(숫자 값 또는 기호)을 사용하여 보고할 오류 메시지를 지정하는 바이너리 비트 마스크를 만드는 것입니다. 비트 연산자를 사용하여 이러한 값을 결합하거나 특정 유형의 오류를 마스킹할 수 있습니다. php.ini에서는 '|', '~', '!', '^' 및 '&'만 올바르게 구문 분석됩니다.
사용의 관점에서 보면
사용자가 수동으로 던진E_USER_NOTICE
, E_USER_WARNING
세 가지 범주로 나눌 수 있습니다. , E_USER_ERROR
, E_USER_DEPRECATED
사용자 원인E_NOTICE
, E_PARSE
, E_WARNING
, E_ERROR
, E_COMPILE_ERROR
, E_COMPILE_WARNING
, E_STRICT
, E_RECOVERABLE_ERROR
php 커널E_CORE_ERROR
, E_CORE_WARNING
에 의한 것인지의 관점에서 프로그램 실행 종료 봐요, 두 가지로 나눌 수 있어요
프로그램 실행 종료
프로그램이 종료되고 오류 처리 과정에 들어갑니다
프로그램 실행을 종료하지 않습니다
오류가 발생하지만 프로그램은 계속 실행될 수 있으며 오류 처리 프로세스로 들어갈 수도 있습니다
PHP의 오류 유형은 다음을 참조하세요. 더 자세한 기사--PHP의 오류 메커니즘 요약
수동 - 런타임 구성에 대해 자세히 설명되어 있지만 여전히 특별한 주의가 필요한 몇 가지 구성이 있습니다
error_reporting
오류 유형을 보고하려면 개발/테스트 환경에서 E_ALL
을 구성하는 것이 좋습니다. 모든 유형의 오류를 해결한 후 프로덕션 환경에서 E_ALL & E_DEPRECATED
을 구성하는 것이 좋습니다. : 오래된 오류를 제외한 모든 오류를 보고합니다
display_errors
오류를 표시할지, 프로덕션 환경에서 false로 구성하고 위의 error_reporting
설정과 일치하는지, 의미: 오래된 오류를 제외한 모든 오류를 보고하되 오류 메시지를 표시하지 않습니다.
log_errors
오류 로깅이 켜져 있는지 여부는 프로덕션 환경에서 위의 두 가지 구성을 사용하면 보고서가 삭제됩니다. 오류를 제외한 모든 오류의 경우 오류 메시지가 표시되지 않지만 오류 메시지가 기록됩니다(PHP 자체에서만 오류 메시지를 조작할 수 있습니다). )를 로그에
error_log
잘못된 파일을 지정합니다(syslog는 특수 값입니다). 수동:
이 구성이 설정되지 않으면 오류 메시지가 SAPI 오류 로거로 전송됩니다.
일반적으로 , 설정하지 않으면 apache/nginx의 오류 로그에 기록됩니다. 위의 세 가지 구성을 사용하면 더 이상 사용되지 않는 오류를 제외한 모든 오류를 보고합니다. 오류, 오류 메시지가 표시되지 않지만 apache/nginx에 기록됩니다. 파일 경로가 구성된 경우 오래된 오류를 제외한 모든 오류를 보고합니다. 오류 메시지는 표시되지 않지만 file_dir
로그에 기록됩니다.
위 내용은 다음과 같습니다. 구성은 PHP 오류의 가장 기본적인 성능에 영향을 미칩니다. 물론 이러한 구성은 ini_set()
또는 php-fpm 구성 변경
가장 주의해야 할 것은 set_error_handler
과 set_exception_handler
입니다. 위에서 언급한
은 오류가 발생한 후에 발생하는 현상을 본 적이 있습니다. , 오류 처리 프로세스가 수행됩니다. 오류 프로세스는 어떻게 정의됩니까?
먼저 PHP 설명서의 설명을 살펴보겠습니다. 오류
간단히 말하면 기본 처리 흐름은 구성을 통해 완료되지만 사용자 정의 오류 처리 흐름을 설정할 수 있습니다
위에서 언급했듯이 두 종류의 오류가 있는데, 스크립트 실행을 종료시키는 오류는 어떻게 처리해야 할까요? set_error_handler
무시하기 쉬운 오류는 처리할 수 없습니다.
이 문제는 기본적으로 다음과 같이 해결됩니다(아직 다른 솔루션을 본 적이 없음):
// 终止脚本的错误会终止脚本执行 // 即会调用已通过register_shutdown_function注册的处理函数 // 由此可注册我们的错误处理流程, 这样就进入了自定义错误流程 register_shutdown_function('FatalErrorHandle'); ... FatalErrorHandle(array $error = null) { ... if (null === $error) { // 通过这种方式可以获取最后一条错误 $error = error_get_last(); } ... // log or other logic }
w3cPHP 예외 처리 설명에 따르면:
예외 처리는 지정된 오류(예외) 조건이 발생할 때 스크립트의 일반적인 흐름을 변경하는 데 사용됩니다. 이러한 상황을 예외라고 합니다.
예외가 트리거되면 일반적으로 발생하는 상황은 다음과 같습니다.
현재 코드 상태가 저장됩니다.
코드 실행이 다음으로 전환됩니다. 사전 정의된 예외 처리기 함수
상황에 따라 프로세서는 저장된 코드 상태에서 코드 실행을 다시 시작하거나, 스크립트 실행을 종료하거나, 코드 내부 또는 외부 위치에서 스크립트 실행을 계속할 수 있습니다.
잡지 못한 예외는 스크립트 실행을 종료하고 E-ERROR 오류를 생성합니다. 정의된 예외 처리가 실행되지 않으면 PHP의 기본 오류 처리 프로세스가 수행되며 이는 로그에 기록됩니다. 하지만 프로그래밍 개념상 예외는 오류와 분리되어야 합니다. 예외는 사용자가 예측할 수 있고 기대에 미치지 못하며 제어 가능한 구조를 가져야 합니다.
위에서 언급한 set_exception_handler
은 예외를 처리하는 데 사용됩니다. 사용법은 set_error_handler
과 동일합니다. 각 프레임워크의 예외 처리는 일반적으로 set_exception_handler
의 프레임워크 처리 가능 수준으로 이전됩니다. 예외 처리에 대한 사용자 제어 목적을 달성하기 위해.Exception
런타임 구성
오류 처리 기능
PHP의 오류 메커니즘 요약
예외
오류
PHP 예외 처리
Symfony 디버그: 완성된 애플리케이션이라고 할 수 있습니다. 종합적인 안내 튜토리얼이 되려면 오류에 관련된 모든 지식이 포함되어 있으므로 소스 코드를 읽는 것이 좋습니다.
위 내용은 PHP 오류 처리 문제의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!