Asked  2 Years ago    Answers:  5   Viewed   119 times

How can i handle parse & fatal errors using a custom error handler?

 Answers

2

Simple Answer: You can't. See the manual:

The following error types cannot be handled with a user defined function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and most of E_STRICT raised in the file where set_error_handler() is called.

For every other error, you can use set_error_handler()

EDIT:

Since it seems, that there are some discussions on this topic, with regards to using register_shutdown_function, we should take a look at the definition of handling: To me, handling an error means catching the error and reacting in a way that is "nice" for the user and the underlying data (databases, files, web services, etc.).

Using register_shutdown_function you cannot handle an error from within the code where it was called, meaning the code would still stop working at the point where the error occurs. You can, however, present the user with an error message instead of a white page, but you cannot, for example, roll back anything that your code did prior to failing.

Tuesday, August 30, 2022
1

You have issue with php default and short tags.

<? ... ?>   PHP short tag
<?php ... ?> PHP default tag

See here for more details

Please replace your last few lines with following code

<?php
}
function add_bxjs() {
    /*wp_enqueue_script(
        'custom-script',
        plugins_url('/bxslider/jquery.bxslider.js', __FILE__ ) ,
        array( 'jquery' )
    );*/
    wp_enqueue_style('bxstyle', plugins_url('/bxslider/jquery.bxslider.css', __FILE__ ));
    wp_enqueue_script('jquery',plugins_url('/bxslider/jquery.min.js', __FILE__ ), array('jquery'));
    wp_enqueue_script('easing',plugins_url('/bxslider/jquery.easing.1.3.js', __FILE__ ), array('jquery'));
    wp_enqueue_script('bxscript',plugins_url('/bxslider/jquery.bxslider.js', __FILE__ ), array('jquery'));
}

add_action( 'wp_enqueue_scripts', 'add_bxjs' );
?>
Monday, October 24, 2022
 
maarten
 
5

EDIT: I created a package that implements behavior described below.

Yii2's error handler cannot be configured in this way. But it is possible to create own error handler, extending yiiwebErrorHandler (or yiiconsoleErrorHandler if required).

namespace appweb;

use yiiwebErrorHandler as BaseErrorHandler;

class ErrorHandler extends BaseErrorHandler {


    /**
     * @var array Used to specify which errors this handler should process.
     *
     * Default is ['fatal' => true, 'catchable' => E_ALL | E_STRICT ]
     *
     * E_ALL | E_STRICT is a default from set_error_handler() documentation.
     *
     * Set
     *     'catchable' => false
     * to disable catchable error handling with this ErrorHandler.
     *
     * You can also explicitly specify, which error types to process, i. e.:
     *     'catchable' => E_ALL & ~E_NOTICE & ~E_STRICT
     */
    public $error_types;

    /**
     * @var boolean Used to specify display_errors php ini setting
     */
    public $display_errors = false;

    /**
     * @var string Used to reserve memory for fatal error handler.
     */
    private $_memoryReserve;
    /**
     * @var Exception from HHVM error that stores backtrace
     */
    private $_hhvmException;

    /**
     * Register this error handler
     */
    public function register()
    {
        // by default process all errors
        // E_ALL | E_STRICT is a default from set_error_handler() documentation
        $default_error_types = [ 'fatal' => true, 'catchable' => E_ALL | E_STRICT ];
        // merge with application configuration
        $error_types = array_merge($default_error_types, (array) $this->error_types);

        ini_set('display_errors', $this->display_errors);
        set_exception_handler([$this, 'handleException']);
        if (defined('HHVM_VERSION')) {
            set_error_handler([$this, 'handleHhvmError'], $error_types['catchable']);
        } else {
            set_error_handler([$this, 'handleError'], $error_types['catchable']);
        }
        if ($this->memoryReserveSize > 0) {
            $this->_memoryReserve = str_repeat('x', $this->memoryReserveSize);
        }
        if ($error_types['fatal']) {
            register_shutdown_function([$this, 'handleFatalError']);
        }
    }

}

Then it is possible to configure the error handler:

'components' => [
    'errorHandler' => [
        'class' => 'appwebErrorHandler',
        'error_types' => [
            'fatal' => true,
            'catchable' => YII_DEBUG ? (E_ALL | E_STRICT) : false
        ],
        'display_errors' => ini_get('display_errors')
    ],
],

In this example configuration we say that error handler should always handle fatal errors, but handle catchable errors only if we are in debug mode. In production mode all catchable errors will be handled by internal php error handler and will appear in error log if you configure it.

display_errors is said to inherit server php configuration from php.ini or .htaccess.

Tuesday, September 20, 2022
 
ylisar
 
5

Change

$data[$parts[0]] = $parts[1];

to

if ( ! isset($parts[1])) {
   $parts[1] = null;
}

$data[$parts[0]] = $parts[1];

or simply:

$data[$parts[0]] = isset($parts[1]) ? $parts[1] : null;

Not every line of your file has a colon in it and therefore explode on it returns an array of size 1.

According to php.net possible return values from explode:

Returns an array of strings created by splitting the string parameter on boundaries formed by the delimiter.

If delimiter is an empty string (""), explode() will return FALSE. If delimiter contains a value that is not contained in string and a negative limit is used, then an empty array will be returned, otherwise an array containing string will be returned.

Friday, September 16, 2022
 
mrso
 
2

AccessDenied incorrectly extends AppError. super() results in injector being undefined, and injector shouldn't be optional in AppError constructor, because it is required.

It could be fixed by making a parameter obligatory:

constructor(private injector: Injector, public originalError?: any) {
    this.toastrService = this.injector.get(ToastrService);
}

The constructor can be omitted in AccessDenied. And should be instantiated like new AccessDenied(injector).

The real problem here is that AppError does the work it isn't supposed to to. Considering that it just contains the error that can be later determined with err instanceof AppError, it shouldn't do side effects that are currently done in handleError.

The logic in handleError could be moved to a method in ToastrService or separate error service that accepts an instance of AppError. If there's a need to provide default message for error type like Access denied error occurred, AppError can have public property that contains the message.

Tuesday, November 29, 2022
 
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :
 

Browse Other Code Languages