I think it's important to differentiate between the different types of errors that you're handling. For errors that are caused by invalid user input, it's a good idea to create an error page that tells them what to correct in their input - probably including the current input you've got and pointing out what needs to be fixed.

For anything that is outside of the user's control (missing files on the server, invalid permissions, that kind of thing) I think that it's a waste of time creating clever error reporting pages. You're probably not going to give the user any information that will mean anything to him than the default web server error page and you run the risk of giving a passing cracker too much information.

The "vanilla" 500 Error page is fine for most purposes. Of course, there's nothing to stop you replacing it with another that better reflects the look and feel of your site.

"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

I like eval blocks

eval {
    #any code in here
    yourSub();
}
if ($@){
    # $@ contains err message if error occurs
    warn " continue with script but there has been an erro $@ \n";
    #run error handling routine
    ErrorHandle();
}
[download]

The average user finds a standard Apache error page v scary so I try and make an error doc for every error possible.

 
ErrorDocument 404 /missing.html
ErrorDocument 401 /auth_error.html
[download]

Update amended to consider below

Two important pieces of advice.

The first is to pick an indentation style indenting between 2-4 spaces, and then start using it. Now. Running your code through perltidy will show you what it looks like.

The second is to call functions with explicit parameters. That means using parens. As documented in perlsub, if you use just the plain & and in a function you call another function, that other function will get the parameters to the first as arguments.

Believe me. You may think these are picky details. But they are not. The first strongly impacts how easy it is to pick out your logic at a glance. The second is causing a subtle set of side-effects that may or may not be intended which a maintainance programmer may or may not know enough to notice.

use CGI::Carp qw(fatalsToBrowser);

die "Error! $error" if ($error);
[download]

gkinueliileunikg

Whilst this is great to use when you're developing a script, I wouldn't advise using it in production code. This is because the error messages that it gives can be a source of useful information for anyone trying to crack your site. In some cases, just knowing that you've got Perl installed on you server can give crackers a head start.

Error messages like this belong in the server error log where the webmaster can read them. There's a good reason why Apache gives a plain 500 error page by default.

--
<http://www.dave.org.uk>

"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

It almost sounds like you're warning people away from using CGI::Carp entirely. (You probably aren't, but I wanted to post this for the benefit of other readers that might also be confused.) It's mainly the fatalsToBrowser and warningsToBrowser bits that we don't want to see in production code. CGI::Carp's primary purpose is to format out nice, debug-friendly error messages in your server's error logs, so I definitely recommend its use even in production code.

Thanks for the hint, but CGI::Carp is out of the question. I need something that produces an errorpage in the same style as the application ist.

CGI::Carp can easily be told to use your own template or function for generating the error message to the user. Check out the documentation for specifics.

eval{ ...code...};
if ($@) { handle error }
[download]

use Error;

try{
  do something...
}catch Error::Simple with{
  handling...
}finally{
  ...
}
[download]

Looks like Java code

You say that like it's a good thing :)

--
<http://www.dave.org.uk>

"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

BEGIN{
  use CGI::Carp qw(carpout);
  open LOG, $logfile or die "Couldn't open log file: $!";
  carpout(LOG);
}
[download]

-- Brett

Go not to the Elves for counsel, for they will say both no and yes

I mean application level error. How does your own exception handling routine look like?
I usually write a database-abstraction-layer (and plan to write a general modul for this purpose). I'm not sure how I should handle errors that occur in this layer. Should the script specify an error template and the database-layers shows this page if an error occurs? Or should the database-layer only return a false value and stores the errortext/-code in a datastructure? The script then can retrieve this errortext and prints the errortemplate.

One thing to keep in mind is the difference between development/debugging error messages, and the user friendly error messages that should be displayed to actual users. Most users don't know what to do with a stack trace or a DBI error message - and as someone else already mentioned, that can be a security risk. Useability folks will scream if you mention anything technical in an error message.

On the other hand, carp, die() and company are your friends during dev.

I like to wrap most everything in eval{} blocks so that major errors can be wrapped with user friendly text, and uses UNIX::Syslog to log error messages. This gives me the chance to grab the $DBI::errst which typically has some great debug info in it for db errors.

This works great for production, but we tend to leave the eval{}'s out while first coding something - verbose error messages are a big help while debugging. Unfortunately, doing anything as a two pass operation means sometimes the eval{}'s don't get added before it goes to production.

I like the idea of putting code in eval-blocks, but is this also efficient/state-of-the-art/perlish?

eval {
    open(FH, $file)         or die "NO_OPEN";
    $text = join('', <FH>)  or die "NO_READ";
    close(FH)               or die "NO_CLOSE";
}
if ($@) { ... }
[download]

instead of

open(FH, $file)            or &error("NO_OPEN",  $file, $!);
my $text = join('', <FH>)  or &error("NO_READ",  $file, $!);
close(FH)                  or &error("NO_CLOSE", $file, $!);
[download]

What approach do you find better?

You can (as in "have the potential to be able to") recover in the eval block. Can you recover in your error sub? I find the block more flexible that way, if that's the sort of thing that's necessary.

(Feel free to drop the leading ampersand. It doesn't add anything in this case, and is often better removed.)

In your example, the second option is actually more readable. But if the function call on the left is longer, and you start wrapping things will get pretty ugly. What's more, if you do something like $sth->execute and the transaction fails (e.g. from bad SQL or an RI constraint) $sth->execute will call die() for you - and an eval block is the only way to catch it.

I prefer to use the same method for something every time - so I go for nothing but eval blocks. Using two different constructs to do the same thing in the same bit of software just makes things harder to maintain. YMMV.