Re: Re: [CALL FOR VOTES] File_IMC

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?

This can only cause issues later. Incidentally, from a bug perspective, I see you have setErrorHandling() in there now, but always pass PEAR_ERROR_PRINT in Build.php, instead of the current error handling value.

Fixed locally, after I get your response about the above, I'll repackage and upload.

Also, Parse.php's _parseBlock() method needs an @access private, it's the only method you missed in your spectacular documentation frenzy :) (believe me, I approve).

Fixed.

Incidentally, my personal opinion is that if a parameter can have only 2-3 types, you should use the types separated by | like @param string|array

Fixed. :) -- Marshall Roch http://pear.php.net/user/mroch