[Openinteract-dev] Re: SPOPS error handling

[Chris W. <ch...@cw...>]

* Ray Zimmerman (rz...@co...) [011022 09:32]:
> Chris,
> 
> For the error handling in our apps we've decided to use a sub-class 
> of the Error class (as in Error.pm from CPAN) and just do something 
> like ...
> 
> 	die new My::Error('message', $other, $error, $info)
> 
> ... where the constructor for My::Error records the stack trace, etc, 
> and then use an eval block and "if ($@)" to catch it elsewhere. In 
> the "if ($@)" part we can handle different types of error objects 
> differently if desired.
> 
> We'd like to be able to handle our SPOPS errors in the same 
> framework, but it isn't quite as clean as we'd like. Since an SPOPS 
> error dies with a string, we have to somehow determine from that 
> string whether it was SPOPS that died or something else (not sure how 
> to do this), then, if it was SPOPS, go get the info from the SPOPS 
> error variables.
> 
> So, I was wondering, why do you use the "put the error info into some 
> error variables and die with a string" approach rather than "put the 
> error info into an object and die with that object" approach to error 
> handling in SPOPS?  Maybe there is an advantage I don't see. And the 
> follow-on question, in case it turns out the latter is more desirable 
> ... would you consider changing it?

I'm including this entire message rather than snipping because it was
sent a month ago. Since I just released 0.53 I'm thinking about the
next version. I'd like to start working on this not only for the
reasons Ray mentions above, but also because some of the discussion on
the P5EE mailing list [1] has led me to think throwing exceptions is a
smart way to do error handling.

Rather than reinvent the wheel (for which I have an unfortunate but
admitted tendency), I figured a good place to start would be the
Exception::Class module. Dave Rolsky has been using it for a while
with Alzabo and other projects with success, plus it's used in the
libservlet API [2] and will probably be used as a core component in
the P5EE effort.

One of the attractive side-effects of this effort will be cleaner
error handling -- most exception frameworks allow only a message to be
associate with an exception, since the type of exception itself
reveals much about the error encountered.

So pop up if you have any opinions or questions about this.

Thanks,

Chris

[1] P5EE mailing list and info - http://p5ee.perl.org/
[2] libservlet - http://sourceforge.net/projects/libservlet/

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.