By default, Web:Extend will catch all exceptions and print an error page. The framework also transforms any triggered error in an ErrorException which are then catchable like any other exception. The error page contains generic information about the error and a few instructions to help the user of the application. In DEBUG mode, the page will also contains a detailed report on the error, including a trace, if available.

You can customize the error page and set up your own instead of the generic one. To do this, simply call weeException::setErrorPage with the path to the error page file. This file will then get included, which means it can be a PHP script or just a simple HTML file. It will also be provided with $aDebug, an array containing debugging informations. You are free to use it or to ignore it.

Here is an example calling this method:

<?php

weeException::setErrorPage(ROOT_PATH . 'app/tpl/error_page.tpl');

The $aDebug array contains the following values:

You can take a look at the default error page located at trunk/res/wee/error.htm for a detailed example using this array.

Avoid throwing exceptions directly using the throw keyword. If you make a typo in the exception's name, it will result in a fatal error.

The framework defines the burn function for throwing exceptions. It takes two parameters: the exception name and the error message. If the exception doesn't exist, a DoubleFaultException is thrown instead. If you really need a script to finish properly, catching Exception directly will ensure there is no problem, even if you made a typo.

A few examples:

<?php

// Instead of this...
throw new Exception('Oops!');

// Do this!
burn('Exception', 'Oops!');

// You can also use it this way:
$r = fopen('/path/to/file', 'r')
	or burn('FileNotFoundException', 'The file /path/to/file does not exist.');

As explained before, when an error is triggered, the default error handler throws an ErrorException with the same informations as the triggered error. The default error handler totally ignores the error level set through error_reporting so every catchable error is caught by it.

The following snippet demonstrates how to catch PHP errors.

<?php

try {
	$a = array();
	echo $a[42]; // triggers a notice
} catch (ErrorException $e) {
	echo $e; // echoes "Undefined offset:  42"
}

The shut-up operator @ should be used only in the following two conditions:

It is a really bad practice to use it when combined with an instruction that might include or parse a PHP file, as it would mask the error and display a blank page.

The following rules define how the developer can choose between the various exceptions:

Only for the last 2 cases the docComment should inform the developer of the exceptions that can be thrown by the function or method.

There is no need to check for invalid arguments unless not doing so could result in an illegal state. For example, the checks done in weeAuthDbTable::__construct are important because without them invalid arguments would not prevent the construction of the object and yet the authenticate and authenticateHash methods would always fail, thus rendering the object useless.