PHP Error Handling Explained

A requirement for any mature application is to expect and handle errors throughout its lifetime. The purpose of handling is to classify and record what happened (to be later fixed) then produce a response back to caller depending on cause. PHP originally came with a very primitive self-handling system where one could toggle whether or not errors should be displayed on screen, error levels to be ignored by handler and an automated logging system to error_log. Soon this behavior has proven to be too inflexible for large applications, so exceptions were added (following Java's model) and a number of procedural functions able to redirect errors to exceptions.

What kinds of errors can occur in a PHP application?

Like any other scripting language, PHP has two types of errors:

How can they be handled?

Ideally, errors should have thrown an exception able to be user-handled (to make the the whole process of error handling controllable from a single point), but up until version 7.0 users had to manually direct self-handled errors & uncaught exceptions to user-defined exceptions in order to achieve a single point of control for errors flow. Redirection is done via following native functions:

This functionality, primitive as it is, provides a hook for an aspect-oriented layer that non-destructively listens to application for cross-cutting concerns (errors), keeping all other components strictly dedicated to their purpose and oblivious of error handling.

What does Lucinda think about this?

STDERR MVC API, part of Lucinda Framework, comes as a revolutionary solution that applies aspect-oriented principles in error handling and MVC principles in the way it works.