Error checking is actually taken care of by "use autodie;". I personally don't like to do that because often a die message can explain to the user the context of what is happening in addition to the actual file that couldn't be opened, e.g. "can't open configuration file: $file_name". This sort of thing becomes more important if there is a GUI involved as opposed to a command line.

Also other "tweaking" of the die message can be done. There is a difference between  die "xyzzy" and die "xyzzy\n" This controls whether or not the user gets the Perl line of code number. Sometimes, it can confuse users if too much info is given with terminology that they don't understand.

###### with auto die ######
open XXX, '<', "XXX";
#Can't open 'XXX' for reading: 'No such file or directory' at C:\Proje
+cts_Perl\testing\die_messasges.pl line 7

###### without auto die ###
# trailing \n in the die message suppresses the line number.
open XXX, '<', "XXX" or die "couldn't open Config file, XXX!\n";
# couldn't open Config file, XXX!

open XXX, '<', "XXX" or die "couldn't open XX file!";
#couldn't open XX file! at C:\Projects_Perl\testing\die_messasges.pl l
+ine 5.

open XXX, '<', "XXX" or die "couldn't open config file XX!, $!";
# couldn't open config file XX!, No such file or directory at C:\Proje
+cts_Perl\testing\die_messasges.pl line 6.
[download]

update:
I didn't show every possibility.
Some points: 1)autodie is pretty cool, especially for short quick scripts. But, there is no context information. In a complex app, it may not be apparent to the user what this file is about. 2) Add or not the trailing "\n" to a die message to control reporting of Perl line number. 3) Often $! is just confusing noise depending upon the App. I use all of the above options in one situation or another. I can't say: "always do it way #X".