Do NOT use Error, because it can cause memory leaks in a number of situations.

For an explanation/overview of existing modules, see CPAN search-results for Error

Being far from a thourough explanation of the concepts, a search on perldoc.com point to a few interesting locations in the docs.

Keep us posted on your searchresults elsewhere, it's IMHO an interesting topic...

For starters, there is the simple "do or die" syntax known from such "phrases" as

open(....) or die "Could not open ... $!\n";
[download]

Some modules deliver errors in parameters (i.e. returning 0 from a particular subroutine), others die.

Some (like DBI with it's RaiseError/PrintError can do either or both.

There are several modules that install their own handlers for die/warn, the most used is probably CGI::Carp which shows the error messages on the browser screen instead of in the web server's error log.

If you want to handle errors differently, in a java-ish, object oriented way, you might want to check out Error. It implements the try/catch method of error handling.

You might find Best Practices for Exception Handling a good read.

If there's a method better than either of these, please let me know.

Class::Exception to create the nested error classes,

Exception::Class... m'thinks :-) (which I agree is very nice)

and Error to create syntax to catch exceptions.

I have to admit I shun the syntactic sugar and just use plain old if statements. Avoids the whole accidentally-creating-closures issue / memory leak issues.

Write a module for a common task or event you plan on using across numerous projects and that would apply to numerous projects. In my opinion error handling does not fall into that category.

The main thing you should do with seeting up your logic flow for your project is handle ALL errors first in each situation. If you are envoking @ARGV at the command line then parse all command line args first and handle every possible error that could happen at command line (like typos or missing arguments) and then if all args pass then handle the obviously correct input (due to passing your error handling) accordingly.

Ex:

#!/usr/bin/perl -w

use strict;
# Error checking!
die "Required argument missing!\n" unless ($#ARGV > 0);

# This along with the following code ensures a positive numeric range.
my $last = 0;

# More Error handling!
for (@ARGV) {
    # Ensures numeric input!
    die "Argument \"$_\" is not numeric!\n" unless (/\d+/);
    # Ensures a negative number was not entered as first argument and
    # also that the second argument is higher in value then the first.
    die "Invalid range!\n" unless ($_ > $last);
    $last = $_;
}

# Here we know that there was some sort of input at command line.
# We also know that each argument is numeric.
# We also know that the user gave a valid range in order for the app
# to print out a consecutively increasing numeric count.
# So with all the error handling passed if the program gets to this po
+int.
# we know we have the required VALID command line input in order for u
+s to
# successfully run this program.
for ($ARGV[0] .. $ARGV[1]) { print; print"\n"; }
[download]