|
Tuesday 22 March 2011 6:36:57 am
Hi there, I'am currently trying to sort out a good way to handle errors in ezPublish modules. In the past we always have been using the default kernel errors. return $module->handleError(eZError::KERNEL_ACCESS_DENIED,'kernel');
In Most cases this method is just fine, especially because it produces no configuration overhead. Some time ago I have discovered the error.ini mechanism to generate custom errors. The mechanism to define custom errors seems to follow the traditional ez way (much configuration and glue). To be able to signal one custom error, i have taken the following steps:
- Define [Error-<name>] section in the error.ini
- Create an interface containing the error codes as symbolic constants
- Create an error template in the subdirectory of the newly defined errortype
So far this is pretty streight foreward but a major drawback is the difference between symbolic PHP error constants and numeric ini values. Because INI files do not know about PHP constants, I cannot use them in the error.ini and thus have to use the numeric values that prior where hidden behind class constants. Because of this flaw the advantage of using constants instead of magical numbers is lost. If a want to change the magic number representing a custom error, i have to look through all ini files and change the magic numbers there as well. Also one always has to switch between the INI file and the error code definition to figure out the meaning of an error code. This is pretty bad for maintainability, especialy if you work on a large project that involves many developers. Also there is an inconsistency in the handleError method of ezModule. As first Argument we use a class constant defined in ezError. The name of the class constant is due to the KERNEL_ prefix restricted to the kernel extension. The second parameter is passed as string. Due to the above described problems, i came up with the following solution. Why not abandon the class constants and use human readable identifiers in both PHP and INI files. [ErrorSettings-gallery]
# use symbolic names instead of numbers
HTTPError[to-large-to-copy]=502
ErrorHandler[to-large-to-copy]=embed
EmbedURL[to-large-to-copy]=user/login
<?php
// do stuff
if(ERROR_CONDITION)
return $module->handleError('to-large-to-copy','gallery');
This approach breaks the ez convention of defining error codes as numbers but the kernel/error module seems to handle this pretty well. After the above code, the template "error/gallery/to-large-to-copy.tpl" will be included and output a helpful context aware error message. What do you thing of this approach? Are there any concerns regarding compatibility or general programming style? thanx for you opinion, ben
|
