Re: error handling

On 08/09/2007, Bill Shupp <hostmaster@shupp.org> wrote: > Hi Folks, > > I'm trying to finish up a new package, and am having some difficulty > with proper error handling. I see that PEAR_Error is deprecated in > favor of PEAR_Exception. But exceptions seem to be overkill for some > of the things I used to use PEAR_Error for, such as passing around > error codes and messages as return values from methods. > > For example, in this context, my class talks to a tcp daemon that may > return an error code and string for a command, but it's not something > I'd want to throw an exception for in my class. Rather, it would be > handy to pass back an error object like PEAR_Error. But will using > it in this manner keep the package from being compliant with PEAR > error handling guidelines, and perhaps not accepted? Is there > another way to handle this that I'm not considering? > > Thanks, > > Bill Shupp In File_MARC, I initially used a child of PEAR_Exception for all error cases, including MARC format violations. However, as I worked with a broad set of MARC records, I quickly learned that almost every set of MARC records contains minor format violations. As throwing an exception during the processing of the record effectively resulted in the iterator coming to a halt, I ended up adding an "array $warnings" property to the class definition instead, to enable parsing to continue with format warnings accumulated in the instance... saving the exceptions for true error cases. I believe this is consistent with PEAR standards. Which reminds me, I better stabilize File_MARC real soon now. -- Dan Scott Laurentian University