use Error qw(:try);
use Error::File; # This is something you write

use IO::File;

# Stuff here ...

my $fh = try {
    IO::File->new($filename) || throw Error::File -text => $!;
} catch Error::File with {
    my $err = shift;
    die "Cannot open file\n";
};
[download]

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

I should probably write a Perl Monk Meditation on this subject as it seems to be coming up a lot lately and I have had to deal with this in many ways over the years.

CAVEAT:You will see some code here that has missing elements such as a lack of initialization and stuff like that. I am going to hand wave all of that so get over it.

Opening files and such

I tend to bury opening of files inside of OO modules and or subs and return the results unless the main purpose of the script is processing the file itself. (did that make sense?) For instance, here is a sniglet of code from a firewall log processor I wrote many many moons ago:

#
# code preceded this....

use vars qw @ $ip_pairs @;

my $ip_pairs = undef;

my ($result,$message)=open_traffic_log();
if ($result){
     # recovery logic goes here....
}

#
# more code after that...

exit(0);

sub open_traffic_log()
{
  if (! open("< fwlog.txt")){
      return(0,$!);
   }
   # Process log file entries here.
}
[download]

That's one of many ways. Another approach that I use particulary within a CGI program.

use CGI;
use CGI::Carp qw / fatalsToBrowser /; # not in production!

my $cgi= new CGI;

#
# stuff

if ( not $cgi->param('paramIReallyNeed')){
   logexeception('paramIReallyNeed was missing from page');
    displayExeptionPage($cgi);
    # Won't return... displayExceptionPage exits.
}

# more code follows.
[download]

Useually though I just invoke either die or carp and move on appropriately.

Other error handling

There are other types of error handling that you need to consider as well. What about a failed fork() call or socket() call?

I have sort of alluded to in a previous paragraph in this post but not spelled out the fact you also have to make the decision if a particular error is a fatal error and you need to stop execution or if it is a "soft" error that you can recover from programmatically.

There is also this little-known feature called if (or even unless). (:

Trying to use the "or die" idiom for something that isn't as simple as "or die" is just a mistake, IMO.

Though, they do have these things called subroutines... :)

open (...) or ($errormsg = $!, $status = -1);
[download]

open (...) or do {
    $errormsg = $!;
    $status = -1;
}
[download]

Makeshifts last the longest.

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

open(...) or $self->checkError(-1, "message with $!");
[download]

For the long term, there is an attractiveness for using exceptions, though I am concerned by some of the comments I've read regarding limitations in the Perl exception mechanism

The only problem I've come across is the lack of direct syntax support. Once you get over seeing eval, die and if ($@) instead of try, throw and catch there shouldn't be any problems.

But then, as you've probably guessed, I have a bias towards exception handling as a "good thing" :-)