While most of the excitement surrounding the release of PHP 5 focused on its XML and object-oriented features, the Standard PHP Library (SPL) also saw some significant improvements that went mostly unnoticed. In the first of two articles covering the SPL, David Fells discusses the Exception class, which lets programs handle errors more gracefully and simplifies debugging.
As I noted before, the Exception object is essentially a data container from the developer's standpoint. The only overridable method is "__toString()", a magic function invoked by default when the class is used in string context. Below is the class definition for the built-in exception class.
class Exception { protected $message = 'Unknown exception'; // exception message protected $code = 0; // user defined exception code protected $file; // source filename of exception protected $line; // source line of exception
function __construct($message = null, $code = 0);
final function getMessage(); // message of exception final function getCode(); // code of exception final function getFile(); // source filename final function getTrace(); // an array of the backtrace() final function getTraceAsString(); // formated string of trace
/* Overrideable */ function __toString(); // formated string for display }
The methods provided by the Exception class allow a developer to get all relevant information required to debug an error. The most useful feature is the stack trace, which was previously only available to developers using the Zend Debugger. The stack trace allows you to follow the code path that generated the exception from end to end, tracing back through calling methods, files and lines, until the source function call is displayed.
In complex applications, this information is truly priceless and eliminates, to some degree, the ad hoc debugging methods typically employed in PHP to trace errors such as inserting "die()" or "print_r()" calls at key places in your code to get a trace. You will still have to do these things from time to time but overall, Exceptions should ease debugging pains considerably. Other methods allow you to retreive the message and code that were passed into the constructor, the stack trace in string format (instead of an array), and the file name and line number where the exception was thrown.
Like most other clases, the base class Exception can and should be extended to fit its intended usage. The purpose of extending the Exception class is, almost exclusively, to allow instantiation of Exceptions with intuitive, specific names rather than the nonspecific (but still intuitive) Exception.
Developers should be very careful in how they extend the Exception class, as the purpose of the class itself requires minimal functionality.If a task needs complex work to take place before an Exception can be built with the proper data, then you would be right to put that functionality into the Exception, but adding functionality for functionality's sake is not the right approach. For example, you would not create several methods to output an error message in various formats. There are already quite a few children of the Exception class in the SPL, all of which are made for use in other SPL classes or by the runtime itself.
