Re: Error handling and Error raising in PEAR

Hi Pierre, I agree it's not always good to use an extended error class. However, I don't think any class should be using PEAR_Error for package-specific errors. If the class has any package-specific errors, I see 2 possibilities: trigger_error() and an extended class. Even something as simple as class Mypackage_Error extends PEAR_Error is fine. The reason for this is that without the ability to tell where an error comes from, it is useless. Current PEAR error handling is not designed for error codes, unfortunately (hence the presence of error message as the first item), and so the pitfalls were not anticipated of making it too easy to not include an error code. There is a solution, and I am 90% through the implementation of it. Basic error throwing is the only thing PEAR packages need to worry about, and I've got a class with a few methods that makes throwing errors with codes/error levels easy. Applications that use PEAR packages need an error handler, and I've designed one of those too. I figured it would be worthwhile to handle PHP errors while I'm at it, so I'm currently in the process of finishing the unit tests on that code. Things it will allow that would be really nice to have (TM): - error message includes file, line and class::function() from debug_backtrace(). It's intelligent enough to extract from eval() and create_function() - error message optionally includes a short stack trace and/or short source code fragment printout - easy logging of errors to multiple sources (screen, file, email) with customizable user levels, full support for PEAR::Log out of hte box, and custom loggers that follow the API - easy assigning of error handlers for specific packages - simulation of try {} catch(), except catch (*) is allowed (catch all errors) - easy use of warnings/notices. There are many error situations that aren't always errors which shouldn't require the return of a PEAR_Error, as only the programmer need know about them. Other stuff too. It's also quite fast and lightweight, as features are loaded on demand, but can be customized easily For a preview of pre-alpha work, you can check out http://www.chiaraquartet.net/apidoc. I haven't uploaded recent changes, and the online version doesn't have stack trace ability Greg Pierre-Alain Joye wrote:

On Tue, 12 Aug 2003 22:18:56 +0200 Alexander Merz <alexander.merz@web.de> wrote:

Greg Beaver wrote:

class PEAR extends PEAR_Error

hm, a really intresting starting point I think i need some days to realize the consequences, it is the first new point of view a side to PEAR_Error2Ext...

Little sidenote. In many cases, we do not need even to include the PEAR_Error and/or PEAR by default. But only when required. Using always our own extended error class is not always a good thing. pierre