Re: PHP5: PEAR base Exception classes

--- Hans <hans@velum.net> wrote: > [Re-post as new thread since this wasn't really a response to Michael's > suggestion of using Exceptions like PEAR_Error.] > > I think it would be great if PEAR provided some re-usable base Exception > classes. Would there be an 'exceptions' package? I don't see any need > to prefix these w/ a category name, though, since they'd be generic: > > I'm thinking in particular of having a few different extension > categories that PHP5 packages *may* use if desired, e.g.: > > - IOException > - MathException > - ... (I'm sure there are many others) That will follow the model of the Java SDK, and might be a good idea for common exception events. > I don't think that every package needs its own Extensions, but in some > cases a given package will want to be able to selectively throw > different categories for handling by the calling code. Exceptions > become useful when you can use hierarchies & selectively catch. Again, > classes could always throw the base Exception object if desired. > > In addition to the categories, there are some Exception features that > would be very nice, for example: > > - NestableException > > This is an Exception that allows you to wrap an existing Exception and > re-throw it without losing any info from the original. This would be > particularly useful for PEAR & should be a base class for the other > Exception types IMO. Yep. Remember that we talked about this over a year ago?: http://marc.theaimsgroup.com/?l=pear-dev&m=104954463104450&w=2 (Some digression on errors and exceptions below, feel free to ignore) Also, in some OOP languages there is a distinction between ERRORS and EXCEPTIONS. In most cases "Errors" are generated by the interpreter or the VM (e.g. Java) because of an unrecoverable error, whereas "Exceptions" are thrown by a program running in the VM (or interpreted by the interpreter) that break the normal flow of the instructions (paraphrased from some Java docs). In procedural programs, the function calls either return error codes, or put an error code in the global space. That is what Greg's PEAR_ErrorStack does to a first approximation. So we have 3 options (which as I'll argue can be reduced to one flexibly): 1) return a PEAR_Error as always (which will not work w/ PHP 5 code cleanly) 2) stick to just exceptions 3) Use PEAR_ErrorStack to generate a PEAR_Error, an Exception or put the error in the global stack If one were writing a package that cannot by any means be written using only PHP 4 syntax and *must* use PHP 5, (2) would be the lazy thing to do (and being a lazy programmer is a "good thing"), (3) would be a better solution. In fact, I would argue that (3) is a better solution no matter if you are writing just for PHP 4, just for PHP 5, or better yet, for PHP 4 now with an eye to PHP 5. Give a read to the good documentation on PEAR_ErrorStack and you'll see what I mean: http://pear.php.net/manual/en/core.pear.pear-errorstack.intro.php > How does one propose code that goes into core PEAR? I imagine that this > would be in something like an 'exception/' dir, but, again, I don't see > any reason to add a prefix as that would be completely redundant (and > make using them just more cumbersome). There is a mailing list for the people working in the core packages of pear, pear-core, so you can propose to them. Cheers. ===== -- Jesus M. Castagnetto (jcastagnetto@yahoo.com) Research: http://metallo.scripps.edu/ Personal: http://www.castagnetto.org/ PEAR stuff: http://pear.php.net/user/jmcastagnetto __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail