openinteract-dev

[Openinteract-dev] SPOPS error handling

[Ray Z. <rz...@co...>]

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?

Thanks,

-- 
  Ray Zimmerman  / e-mail: rz...@co... / 428-B Phillips Hall
   Sr Research  /   phone: (607) 255-9645  /  Cornell University
    Associate  /      FAX: (815) 377-3932 /   Ithaca, NY  14853

[Openinteract-dev] Re: SPOPS error handling

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

* Ray Zimmerman (rz...@co...) [011022 09:32]:
> 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'll have to dig into the history books for this one...

Ah, I kind of remember. I had tried (in OpenInteract) to create a
global error handler, much like the one Matt Sergeant wrote up in the
mod_perl guide. But I had some problems with internal errors being
thrown by some modules NOT being a string -- that is, they expected a
string and died a horrible death when they couldn't examine the
string.

Do I remember the modules or the errors? Nope. This was 2+ years
ago. So instead of looking into it more, I just created the simpler
version we have now. (Lazy)

So I totally agree that it's a better way to do things, particularly
when you frequently get all the error information anyway:

----------------------------------------
my $object = eval { $class->fetch( $id ) };
if ( $@ ) {
    my $error_info = SPOPS::Error->get;
    warn "Error: $error_info->{system_msg}\n";
}
----------------------------------------

So yes, I would definitely change it. The only concern I have is
backward compatibility. There are just a few items with that.

 (1) Create a 'set()' method that is just an alias for 'new()'

 (2) Create a 'get()' method that just returns the last error object
 created, and modify 'new()' to track the last object created.

 (3) Allow people to still inspect $@ as if it were a string. We
 should be able to use 'overload' to stringify the object so people
 can do this. Simple example:

----------------------------------------
package My::Test;

use strict;
use overload '""' => \&as_string;

sub new       { return bless( $_[1], $_[0] ) }
sub as_string { return $_[0]->{user_msg} }


package main;

eval {
    die My::Test->new({ user_msg   => 'This is the user message',
                        system_msg => 'The system is going down!' });
};
if ( $@ ) {
    print "User: $@->{user_msg}\n",
          "Sys:  $@->{system_msg}\n";
    if ( $@ =~ /user/ ) {
        print "Found 'user' in error message!";
    }
}
----------------------------------------

So I think we should be good. (I'll rewrite some code that uses the
errors and see for sure.)

I don't think we need to make any other modifications to SPOPS error
handling. It's very simple and should probably continue to be so.

But...

While we're rewriting it we might want to think about any other
changes -- no reason to change the API multiple times in a short
period :-)

Chris

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

[Openinteract-dev] Documentation patch

[Drew T. <dr...@dr...>]

Hi,

I finally managed to get around to actually installing OI! As such I was 
browsing through the docs and came across a very minor HTML bug. Here's a 
patch for it. I look forward to playing w/ OI in the near future. I'm sure 
I'll have lots of questions... :-)

[drew@nephi oi_docs]$ diff -u admin.html.orig admin.html
--- admin.html.orig     Mon Oct 29 07:39:03 2001
+++ admin.html  Mon Oct 29 07:39:13 2001
@@ -458,7 +458,7 @@
    <li><b>log</b>: Directory where logs are kept. This needs to be
    writeable by the webserver user.</li>

-  <li><b>cache: If you're using the default caching module that
+  <li><b>cache</b>: If you're using the default caching module that
    utilizes the filesystem, the caching will be done in this
    directory. This needs to be writeable by the webserver user.</li>


Drew Taylor                     JA[P|m_p|SQL]H
http://www.drewtaylor.com/      Just Another Perl|mod_perl|SQL Hacker
mailto:dr...@dr...      *** God bless America! ***
ICQ: 135298242

Re: [Openinteract-dev] Documentation patch

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

* Drew Taylor (dr...@dr...) [011029 04:00]:
> Hi,
> 
> I finally managed to get around to actually installing OI! As such I was 
> browsing through the docs and came across a very minor HTML bug. Here's a 
> patch for it. I look forward to playing w/ OI in the near future. I'm sure 
> I'll have lots of questions... :-)

Great! We'll look forward to them :-)

> [drew@nephi oi_docs]$ diff -u admin.html.orig admin.html
> +++ admin.html  Mon Oct 29 07:39:13 2001
> @@ -458,7 +458,7 @@
>    <li><b>log</b>: Directory where logs are kept. This needs to be
>    writeable by the webserver user.</li>
> 
> -  <li><b>cache: If you're using the default caching module that
> +  <li><b>cache</b>: If you're using the default caching module that
>    utilizes the filesystem, the caching will be done in this
>    directory. This needs to be writeable by the webserver user.</li>

Ah, thanks much. Fixed.

Chris

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

[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.