Well error handling for your specific project will be just that, specific to your project. The scenerios you may or may not run into in this particular app will be most likely assosiated to the app therefore an error module probably would be a bad idea.

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]