Re: Error_Raise API change, major 2x speedup question

Hi, Yes, there are several advantages. First, package errors are not always raised in a class with the package's name (DB errors are raised in the mysql driver, for example). In addition, re-packaging errors is not easy (you get a DB error, and want to display it as a CMS error). Also, if you get an error in HTML_Template_Flexy, for example, on line 16 of your template file yyy.tpl, you'll want to display "Flexy error on line 16 in yyy.tpl." Say you want to translate this message to another language with a different grammar order, printf won't work. Or if a user designs a system that will allow displaying just a list of template files and line numbers. You can't extract that information from error messages. My class saves the information in $userinfo so that it can easily be extracted. It also allows re-formatting of error messages for different outputs, i.e. using HTML, ANSI for console, or text for file logs. The most important advantage is warnings and notices. Not all errors should terminate function execution (function, not program - to be clear). function UnsetSomeArrayIndex($index) { if (!isset($myarray[$index])) {

      Error_Raise::notice('mypackage', ERROR_NOT_SET, array('index' => $index)); // let the user know this might be an error, a callback would catch this
      return true; // it did work - we shouldn't return an error.

} } Why is this important? the same reason PHP throws notices for things like accessing variables that were not previously set - it might be an error, but is probably OK. PhpDocumentor really, really needs warnings and notices - and the ability to ignore them. Our current error handling code frankly sucks, and many other applications will also need a much more powerful error handling routine. This is the main thing - PEAR_Error wasn't designed for the kind of advanced error-handling/logging that is needed by most complex applications, and adding in the functionality is really difficult. Error_Raise is designed to be used by the Error_Handler class I've designed, which allows applications to coordinate error messages from different packages quickly and easily at runtime. The splitting of a classname will be much slower when you have 3 error classes for every package (error/warning/notice). I suppose separate classes might not be needed, I originally designed it like that because I planned on using the classname, but if I am using a $_type member (which I am as of today), then only 1 class is necessary. the main thing that is better is error message generation. The current static error message just isn't good enough. I'd be happy to see my error class's benefits merged into PEAR_Error, and in fact, I would like to see that happening, but I would rather see it working independently before any changes are made to PEAR_Error. this would amount to adding the $_package and $_type members to PEAR_Error, and replacing the current getMessage() with my code (it's 100% BC). Then, adding the warning() error() exception() and notice() static methods to PEAR would seal-a the deal-a. Before I sign on this statement, I'd like to finish the code, as this may change. Any other suggestions are appreciated. I should mention that things I must have in the code that PEAR_Error can't do are the ability to generate error messages at runtime based on error code and userinfo, and the ability to create error levels warning/notice/error/exception, that's why I started in the first place. PEAR can do either trigger_error levels or callbacks because of the way that $options is used in the constructor. Greg Alan Knowles wrote:

OK, ignoring the PHP5 issue, since debug_backtrace is in PHP4.3 - is there any advantage in the new error handler over adding the isErrorType logic to the current PEAR_Error, described below..? Regards Alan Greg Beaver wrote:

Alan Knowles wrote:

I thought the general plan was to leave PEAR_Error alone, and try and work out a replacement that uses throw/catch.. in PHP5.. - seems a good point to introduce a major overhall.. Is it really impossible to look up the calling class from debug_backtrace? you could then, just add $error->isErrorType('DB_DATAOBJECT_ERROR_ABCEDFG'); which can exploded on the ERROR, compare it with the class (debug_backtrace) - then compare the error no with the constant($errorstr) Or Did I miss the logic on adding this?

Yes. try/catch cannot be used for warnings/notices. Also, you can't assume that people are going to just start using PHP 5, there will be a need for BC. In addition, this code resolves all of the issues with error messages/error codes, which try/catch will never have any power over.

Greg