Error codes and module results #

Part 8, reference 29. A view that cannot do its job returns an error instead of a result: return $Module->handleError( eZError::KERNEL_NOT_AVAILABLE, 'kernel' );. The kernel then shows the error page for that code, with the right HTTP status, and (for access denied) may ask the visitor to sign in. This page lists the codes and how they are handled.

The kernel codes (eZError, kernel/classes/ezerror.php) #

There are also shop codes (SHOP_*) for the shop module's own errors.

In a view #

<?php
$Module = $Params['Module'];
$itemID = (int)$Params['ItemID'];
$item = myExtItem::fetch( $itemID );
if ( !$item instanceof myExtItem )
{
    return $Module->handleError( eZError::KERNEL_NOT_AVAILABLE, 'kernel' );
}
$access = eZUser::currentUser()->hasAccessTo( 'myext', 'manage' );
if ( $access['accessWord'] !== 'yes' )
{
    return $Module->handleError( eZError::KERNEL_ACCESS_DENIED, 'kernel' );
}

Return the call: the view must end there.

How the kernel handles each code #

settings/error.ini [ErrorSettings-kernel] decides per code:

The error pages are the templates error/kernel/<code>.tpl in the design chain; a theme can override them.

Errors that are not views #

• JSON answers (an Ajax view): set the HTTP status yourself and answer with a JSON body; do not return an HTML error page to a script.
• Command line scripts: write the error with $cli->error() and end with a non-zero exit code (eZScript and eZCLI).
• Fatal PHP errors end in the kernel's general error page; the details go to the log, never to the visitor.

Related pages #

• Previous: Directories under var/
• Next: The expui JavaScript API
• eZModule and module results
• Error templates
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.