Re: Quick question about PEAR_Error

Hi Alan, I wouldn't mind this change, but it hadn't been discussed in the merge - I was simply trying to create something that has 100% BC for starters. It looks like PEAR_Error is inconsistent. Stig, where are you in this discussion? Didn't you design the thing? Greg Alan Knowles wrote:

I thought this type of error modes where to be depreciated, in favour of notice,warning,fatal.... etc. you where going to do somthing like this..? PEAR::setErrorHandling(package,error,callback) In which case just supporting the old format to the minimum (eg. BC level) was Ok... I dont errors raise multiple types at present... Regards Alan Greg Beaver wrote:

Hi, I've started the work of developing PEAR_Error_Lite, and PEAR_Error, and came across a curious design problem. The PEAR_ERROR_* constants (PEAR_ERROR_RETURN, PEAR_ERROR_CALLBACK, etc.) are designed so that $mode & PEAR_ERROR_BLAH can be used to allow multiple simultaneous error modes. This is a good choice. However, setErrorHandling() doesn't work in this way, it uses a switch statement, which means if you attempt to do this: PEAR::setErrorHandling(PEAR_ERROR_PRINT & PEAR_ERROR_CALLBACK, array(&$this, 'errorhandle')); it will fail with "invalid error mode." The question I have is which way should I code for? Is it impossible to have both an error callback and an error trigger/error die/error throw, etc.? Or should multiple modes be allowed? Just as an update, I've got a PEAR_Error_Lite file that contains everything needed for advanced error handling that weighs in at 130 lines. It's 100% forwards-compatible with PEAR_Error, and provides all the basic functionality that fast scripts might need to provide, and is compatible with my Error_Handler package :) All I need to finish it is to resolve this bizarre conflict. Thanks, Greg