error handling

Hi Folks,

I'm trying to finish up a new package, and am having some
difficulty  
with proper error handling.  I see that PEAR_Error is
deprecated in  
favor of PEAR_Exception.  But exceptions seem to be overkill
for some  
of the things I used to use PEAR_Error for, such as passing
around  
error codes and messages as return values from methods.

For example, in this context, my class talks to a tcp daemon
that may  
return an error code and string for a command, but it's not
something  
I'd want to throw an exception for in my class.  Rather, it
would be  
handy to pass back an error object like PEAR_Error.  But
will using  
it in this manner keep the package from being compliant with
PEAR  
error handling guidelines, and perhaps not accepted?  Is
there  
another way to handle this that I'm not considering?

Thanks,

Bill Shupp

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

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

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 08/09/2007, Bill Shupp <hostmastershupp.org> wrote:
> Hi Folks,
>
> I'm trying to finish up a new package, and am having
some difficulty
> with proper error handling.  I see that PEAR_Error is
deprecated in
> favor of PEAR_Exception.  But exceptions seem to be
overkill for some
> of the things I used to use PEAR_Error for, such as
passing around
> error codes and messages as return values from
methods.
>
> For example, in this context, my class talks to a tcp
daemon that may
> return an error code and string for a command, but it's
not something
> I'd want to throw an exception for in my class. 
Rather, it would be
> handy to pass back an error object like PEAR_Error. 
But will using
> it in this manner keep the package from being compliant
with PEAR
> error handling guidelines, and perhaps not accepted? 
Is there
> another way to handle this that I'm not considering?
>
> Thanks,
>
> Bill Shupp


In File_MARC, I initially used a child of PEAR_Exception for
all error
cases, including MARC format violations.

However, as I worked with a broad set of MARC records, I
quickly
learned that almost every set of MARC records contains minor
format
violations. As throwing an exception during the processing
of the
record effectively resulted in the iterator coming to a
halt, I ended
up adding an "array $warnings" property to the
class definition
instead, to enable parsing to continue with format warnings
accumulated in the instance... saving the exceptions for
true error
cases. I believe this is consistent with PEAR standards.

Which reminds me, I better stabilize File_MARC real soon
now.

-- 
Dan Scott
Laurentian University

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php