Get started and transition to PHP7 (4)-the engine that replaces fatal error exceptions

Get started and transition to PHP7 instead of fatal error engine exceptions

The original link of the park learning
Parking Code Show video

Since PHP 4, the error handling of PHP has been almost static. Just add the e_strict in PHP 5.0, add the E_recoverable_error in PHP 5.2, in PHP 5.3, add the ERROR level e_dprecated. Although exception was added to PHP 5, only a few modules in PHP used this mechanism (for example, PDO and SPL). In PHP 7, this embarrassing situation has finally been completely changed.

Engine Exceptions

In PHP 7, almost all of the fatal and catchable fatal error is replaced by the Engine exceptions. However, all exceptions that are not caught will still result in a "traditional" PHP fatal error, so this change is almost forward-compatible for various fatal error. But for other types of error (Non-fatal), because they are also converted to exceptions, ignoring them also results in a fatal error, so the handling of these errors is not forward-compatible.

One of the benefits of unifying errors into exceptions is that we can use Try...catch to handle them uniformly, thus providing many guarantees for the correct cleanup of the wrong site:

• Make sure that the code in the finally is called;

• Ensure that the __destruct () function of the class is called;

• A callback function registered with Register_shutdown_function () is called;

In short, because of the engine exceptions, errors are more difficult to ignore and easier to handle. Let's take a look at an example: what happens to an exception in the constructor?

getMessage();}

In PHP 5, $msg will be a null or unavailable object. In PHP 7, Messageformatter throws a \intlexception exception: Constructor failed.

PHP 7 Exception architecture

In order to be compatible with PHP 5, we must ensure that the previous Call-all notation:

getMessage();}

The new PHP 7 engine exceptions cannot be captured (because Fatal error is not capable of being captured and processed until PHP 7). In this way, those exceptions that are not handled will cause a fatal error as before. Therefore, all new engine exception did not inherit the previous \exception class, but instead inherited a new base class called \error.

class Error implements Throwable { /* Inherited methods */ abstract public string Throwable::getMessage ( void ) abstract public int Throwable::getCode ( void ) ...}

Based on \error exception, 5 new engine exception:arithmeticerror/assertionerror/divisionbyzeroerror/parseerror are derived. TypeError. In PHP 7, both the old \exception and the new \error realized a common interface: \throwable. Therefore, \throwable is the topmost interface in the PHP 7 exception schema. So, if you want to implement a catch-all in PHP 7, you can do this:

getMessage();}

Error exception

Next, let's take a look at each of these new engine exception:

\error

This exception represents the standard fatal and catchable-fatal errors in PHP 7 and, if not caught, triggers a "traditional" PHP fatal error. For example, we call a non-existent method:

try {    nonExistFunc();}catch(\Error $e) {    echo "\Error catch: ".$e->getMessage();}

\assertionerror

If you are in php.ini, set the assert.exception to 1, and when the assertion fails, you will receive this exception:

try {    assert(‘1 > 2‘, ‘1 > 2, are your serious?‘);}catch(\AssertionError $e) { echo $e->getMessage();}

"If we do not set the error message in the Assert (), \asserterror cannot read the error message. ”
Best practices

\arithmeticerror and \divisionbyzeroerror

\arithmeticerror is concerned with arithmetic operations. A \arithmeticerror occurs when an operation is out-of-bounds or a bit shift negative number. For example, the following code causes the "Bit shift by negative number" error.

try {    1 >> -1;}catch(\ArithmeticError $e) { echo $e->getMessage();}

\divisionbyzeroerror, however, represents the error caused by a divisor of 0 (whether we use/% or intdiv (), as long as the divisor is 0, this error will be caused).

\typeerror

We have introduced the scalar type hints and strict mode for PHP 7 in the previous video. Whether the scalar type hints or the traditional type hints (Class/interface/callable/array), a \typeerro exception is caused as long as the type does not match the type hints constraint.

try {    1 >> -1;}catch(\ArithmeticError $e) { echo $e->getMessage();}

Set_error_handler ()

In PHP 7, one thing is incompatible with PHP 5, if we previously used Set_error_handler () processing catchable fatal error, in PHP 7, these error has become the engine exception, They are no longer processed by Set_error_handler ().

Custom exceptions

Although \throwable is the top-level exception interface in PHP 7, it cannot be implemented directly when we customize the exception. Otherwise PHP will prompt us for the following error:

class MyException implements \Throwable {}

Fatal Error:class MyException cannot implement interface Throwable, extend Exception or error instead

In order to properly handle the exception line number, file name, and stack trace, we can only derive our own exception class from \exception or \error. However, we can expand the new \throwable interface and implement the method:

interface MyExceptionInterface extends \Throwable { }class MyError extends \Error implements MyExceptionInterface { }

 

Original: 1190000004219265

Get started and transition to PHP7 (4)-the engine that replaces fatal error exceptions