Re: Re: [CALL FOR VOTES] File_IMC

Marshall Roch wrote:

Greg Beaver wrote:

I'd like to strongly encourage you not to HANDLE errors you raise, but only to raise them - let applications do the handling. This line has been blurred by PEAR_Error, but I think it is always best to let the user control error handling through PEAR::setErrorHandling().

I know that this is a very crude hack, and I don't like it any more than you do. :) The "solution" probably stems from a lack of understanding of how PEAR error handling should work on my part. The examples that I've been able to find don't have many real world examples... but that's another beast. The specific problem here is that I want to be able to use PEAR::isError() in Build.php's addParam(). I really don't want to include all of PEAR.php if it's not necessary, but there isn't really another good way to check for a PEAR_Error object, is there?

I like your solution of including isError() - my only objection is passing in a PEAR_ERROR_* value to raiseError(). The way an error is handled (print, die, callback, whatever) should be application-specific, not package-specific, imo. Let me know if that is any clearer. Personally, I would probably use is_a() and define it at the bottom of your file for those without PHP 4.2.0 if (is_a($err, 'PEAR_Error')) { . . . if (!function_exists('is_a')) { function is_a($obj, $classname) { return get_class($obj) == strtolower($classname) || is_subclass_of($obj, $classname); } } Greg