Trapping errors

[Robert Norris <Ro...@its.monash.edu.au>]

Hi all,

I'm working with Embperl 2.0rc2, using Embperl::Object for the entire
site. I've having some issues with error trapping, and I've been unable
to figure it out by myself, so I seek your advice.

My understanding so far is that compile errors will always cause a 500
error, and so can only be handled with an appropriate ErrorDocument.
Runtime errors, on the other hand, can be handled by my own code (ie
from base.epl).

My usual way of handling errors (ie outside of Embperl) is via a custom
class that contains all the bits I need. When I get an error, I
instantiate this class and then call Carp::croak, eg:

  my $dbh = DBI->connect(...)
  croak(internal::error->new(type => 'db', action => 'retry',
                             text => 'DB connect failed')) if not $dbh;

Then I run stuff inside eval blocks. If I get an error, I test $@ with
UNIVERSAL::isa. If its my class, I handle it one way, if not (ie its a
Perl or 3rd-party module error), I handle it another.

The first thing I did was to port this to Embperl. Rather than calling
internal::error->new, I do:

  my $err = Execute({object => 'util/error.epl'});
  ...
  croak($err->new(...));

And then in base.epl, something like this:

  eval { Execute('*') };
  if($@) {
      Execute('error.epl', $@);
  }

This seemed to work, so I left it there and continued on the rest of the
site. I've since found that it doesn't work all the time, for reasons
that I can't explain (my reading of Embperl::Object::Execute suggests
that it should never work, so I don't know).

On the times it doesn't work, I get the standard Embperl error page.

I've had a look through the mailing lists, and information is sketchy,
but it was there I found out about the "errors" argument to Execute.
I've tried that, but I never get anything returned to me in the error
array.

I've set optReturnError, which isn't making a difference. I get the
error reported in the server log, but nothing else (not even a 500 error
from Apache, interestingly enough).

So where do I go from here? Is there a single way to trap all runtime
errors (Embperl + croak/die)? What distinguishes an Embperl error (ie
something that would be returned in the error array) from any other
error?

Thanks,
Rob.

--
Robert Norris                          <Ro...@its.monash.edu.au>
Messaging & Scheduling Group             Information Technology Services