PEAR's Error Handling and PHP5

I feel like there is a rift opening up in PHP on the subject of Error Handling again. A while ago an RFC[1] that proposed Exceptions as the error handling mechanism for PHP5-only packages and laid out the usage of exceptions. However, there was much debate and some developers have expressed an unwilling-ness to create PHP5 packages due to the rule of using Exceptions for error handling. I'd like to reopne the discussion about this as I would hate for these developers to leave PEAR or PEAR to not get PHP5 packages due to this problem. Some talking points: 1) Would it be possible for us to allow both PEAR_Error and Exception usage for PHP5 packages? Would this fragment our error handling too much? (This would, of course, require a version of PEAR_Error which is E_STRICT). 2) Why are people so opposed to Exceptions form a technical standpoint? Some pros and cons as I see them: Pro Exceptions: * Built into PHP, not as heavy as PEAR_Error (As I remember, this was one of the major upsides of Exceptions due to rampant criticism of PEAR/PEAR_Error as being too heavy) * Allows bubbling up without manually catching and re-returning errors (if the code doesn't handle the error in any way, why force the code to re-return it?) * Understood by programmers of other high level languages as a standard for error handling (C++, Java, Python, etc) * Will lower the number of mixed returns in PEAR code, meaning it will stop users from asking about "undefined method" errors (don't tell me you're not tired of explaining error returns to new users) * [related to above] Will allow for cleaner and simpler example code (no need to catch exceptions, just let them kill the script normally) * Forces errors to be dealt with, it is not possible to forget to check an error return (this is a big pro IMHO) Con Exceptions: * Will cause multiple error handling paradigms to be used at once as likely PHP4 and PHP5 package will be used side-by-side for a time * They don't allow PEAR_Error's tricks such as changing error handling (dying, callback, etc), and expecting errors * To allow code to continue when an error happens Exceptions must be caught, likely for every function call. (This is a con only when doing rapid prototyping and when you *want* to disregard errors. Note that most error conditions will caus ethe script to fail at the same point anyway, so this point is mostly moot for me. When creating a stable package and allowing code to continue you should be catching and storing the errors anyway. This could be done by using PEAR_Error/_Stack and a specialized callback, I suppose...) * They are an implicit goto (this is a very small con as this is essentially the same as returning errors from multiple calls) * Forces errors to be dealt with/rapid protytping becomes a little harder (this is IMHO a very small con, as said above, as most errors will need to be handled before code can continue anyway) -- Justin Patrin