in reply to Re^2: Newby question
in thread Newby question
In the first example, I just have the OS error code $!. Well if the code is opening many files, "which file?" is not known - although you can get the Perl source line that the error occurred on. I don't expect users to have to look into the code so that isn't ideal.
The second example, I put the filename that was trying to be opened into the "die" message. That is often way more useful than the OS error code alone. Usually not to hard to figure out why that file couldn't be opened.
In the third example, I put both the filename and error code. I most often include both pieces of information. Also note that I also put whether a read, write or append was attempted into the error message.
In the fourth example, I suppress the output of the Perl source line number by simply appending a "\n" to the "die" string. In a lot of situations, the user doesn't care about this Perl code line and it just clutters things up and can confuse folks.
#!/usr/bin/perl -w use strict; my $infile = 'bogus_name'; open IN, '<', $infile or warn "$!"; # No such file or directory at C:\TEMP\demoOpenMessage.pl line 6. open IN, '<', $infile or warn "cannot open $infile for reading"; #cannot open bogus_name for reading # at C:\TEMP\demoOpenMessage.pl line 6. open IN, '<', $infile or warn "cannot open $infile for read-> $!"; #cannot open bogus_name for read-> No such file # or directory at C:\TEMP\demoOpenMessage.pl line 12. open IN, '<', $infile or warn "cannot open $infile for read-> $!\n"; #cannot open bogus_name for read-> No such file or directory
|
|---|