Re: error handling

I think Bill is kind of raising a valid point here: What happens if your PEAR package wants to "raise" a warning, deal with it, then continue on with its regular routine? You can't raise an exception because that will jump out to the closest catch right? Then the user can deal with the "PEAR_Warning" as they see fit, printing it, logging it or ignoring it. Justin Patrin wrote:

On 9/8/07, 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?

No PEAR_Error usage is allowed in new packages. All error handling is to be done with PEAR_Exception. If you're just passing things around internally the it will never be thrown outside of the package you could maybe just return a simple assoc array but I would suggest instead using PEAR_Exception for any real errors and having any code that handles such things catcht he exceptions and keep processing from there.

-- David Sanders shangxiao