Because of the design of the code (not to mention my deadlines) refactoring the error code out into a seperate function really isn't possible

Maybe I'm missing something here but, if you're already rewriting these error handling cases to make them more readable, how much more work would it be really to add a sub/module to handle the errors?

You can have the added benefit of working on how to deal with errors more comprehensively over time. For example, here's a snippet of our "fatal error" method under mod_perl (not everything, just the interesting bit, and rewritten to run standalone rather then using some internal methods we use).

sub fatal_error {
    my $err = $_[0];

    my @caller = ();
    my $i=-1;
    while ( caller(++$i) ) {
        (caller($i))[1] =~ /5\.8\.0/ and last; # don't log apache mod 
+in trace
        push @caller, sprintf("-> %s at line %s\n", (caller($i))[1,2])
+;
    }
    open(LOG,">>/path/to/err_log") or die $!;   
    print LOG `date`,"$err\n",@caller,"\n";
    close(LOG);

    # display fatal error page, since this is in a web environment
}
[download]

Like I said, this is just a snippet, leaving out the emailing of the error to me, the logging in the local DB, and the centralised logging for later analysis.

If you start refactoring as you go, you'll have much better control over how errors are dealt with and, when you get an idea on improvement, you can easily add it in.

Yes, deadlines are there, but by not factoring refactoring (intended :) into your time lines, you're creating more work down the line.

If convincing the powers that be of the wisdom of this is problematic, buy your boss a copy of Peopleware, make them read it, then schedule a time where you can discuss the issues it brings up, and how you can implement them to make your work more productive.

Saving time now by ignoring problems is a false economy.

.02

cLive ;-)

ps - oh, and I'd call it like this:

unlink $file or fatal_error("Couldn't delete $file: $!);
[download]