A shutdown handler should be registered to catch fatal error

[Colonel_mortis]

Based on the Whoops code, it should probably look something like this:

public function handleShutdown () {
  $lastError = error_get_last();
  if ($lastError && $lastError['type'] & (E_ERROR | E_PARSE | E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_COMPILE_WARNING)) {
    try {
      \IPS\Log::i( \LOG_CRIT )->write("{$error['type']}\n{$error['message']}\n{$error['file']} line {$error['line']}");
    } catch (\Exception $e) {}
    
    \IPS\IPS::genericExceptionPage();
  }
}

This will prevent a white page on fatal error.

[Marcher Technologies]

...... They already are caught? \IPS\IPS::errorHandler and \IPS\IPS::exceptionHandler....

[Colonel_mortis]

Just now, Marcher Technologies said:

...... They are? \IPS\IPS::errorHandler and \IPS\IPS::exceptionHandler....

Fatal parsing errors aren't caught by them, I'm fairly sure. I've had white pages when there has been a mistake in the code and it hasn't been in dev mode.

[Marcher Technologies]

5 minutes ago, Colonel_mortis said:

Fatal parsing errors aren't caught by them, I'm fairly sure. I've had white pages when there has been a mistake in the code and it hasn't been in dev mode.

The only way I could see that happening by the code is if the line with the error was silenced with @, in which case there's nothing that can be done, and don't do that?

[Colonel_mortis]

Just now, Marcher Technologies said:

The only way I could see that happening by the code is if the error was silenced with @, in which case there's nothing that can be done, and don't do that?

As per the set_error_handler documentation:

Quote

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.

register_shutdown_function is a hacky (but useful) way of overcoming that limitation.

[Marcher Technologies]

7 minutes ago, Colonel_mortis said:

As per the set_error_handler documentation:

register_shutdown_function is a hacky (but useful) way of overcoming that limitation.

fatal errors throw catchable ErrorException's in recent php versions, which is why I didn't quite understand how the error was slipping past. I'm not sure why that hacky approach is needed when mere adoption resolves the issue?

[Colonel_mortis]

Just now, Marcher Technologies said:

fatal errors throw catchable ErrorException's in recent php versions. I'm not sure why that hacky approach is needed when mere adoption resolves the issue?

Only in PHP7. If you vandalise one of the IPS source files and turn off dev mode, you will get a blank page when you try to load it, which means that it's not being caught.

I'm using PHP 5.6, which is the latest version on the 5.x branch (7 isn't officially supported by IPS yet because it's not officially supported by HTMLPurifier).

[Marcher Technologies]

3 minutes ago, Colonel_mortis said:

Only in PHP7. If you vandalise one of the IPS source files and turn off dev mode, you will get a blank page when you try to load it, which means that it's not being caught.

I'm using PHP 5.6, which is the latest version on the 5.x branch (7 isn't officially supported by IPS yet because it's not officially supported by HTMLPurifier).

Had forgotten about that, thanks. Here's hoping htmlpurifier does end up officially supporting it. 7 is a vast improvement in the language for many reasons, including this one...

[Colonel_mortis]

This would be really helpful to stop people from thinking that the site is down when the Content I Posted In query inevitably fails due to a memory cap being hit.