Re: error handling

David Sanders wrote: > I think Bill is kind of raising a valid point here: What happens if your > PEAR package wants to "raise" a warning, deal with it, then continue on > with its regular routine? You can't raise an exception because that > will jump out to the closest catch right? Then the user can deal with > the "PEAR_Warning" as they see fit, printing it, logging it or ignoring it. Hi, There are two ways to handle it. 1) You can use an instantiated exception and rely upon its subject/observer model to track them as "warnings" the same way PEAR_ERROR_CALLBACK was used for PEAR_Error 2) You can use true/false or any other method you'd like internally, and use throw for passing errors out of the package. This last point is *extremely* important. Exceptions are quite expensive, and for private methods where error handling is all internal, I would not use exceptions unless there is an exceptional circumstance (database failure, JFK rises from the dead, etc.) The only rule that the RFC requires is that all errors passed *out* of a package be PEAR_Exceptions. Internal error handling has no limits, you can do anything you want. However, PEAR_Error is more expensive than PEAR_Exception, so if you have to choose, use PEAR_Exception. Greg