Re^2: Testing unexpected I/O failures

G'day Fletch,

Overall, there are a lot of input parameters; currently, there are about 50 possible messages that can arise when the sanity checks are run. Most of these are not related to any file checks: "A can't be zero-length"; "B must be an integer"; "C can't be greater than D"; and so on. There are nine file-related checks as outlined in the OP.

I wanted to get all sanity checks performed prior to starting the processing proper; which begins with opening the input file. I considered it to be more useful to advise the user upfront that there was a specific problem with the directory or file parameter supplied, rather than offering a generic $! message from open, such as "File not found", "Permission denied", or similar.

Your suggestion of doing the open first with supplied values (i.e. dir_param/file_param) and then dealing with failure might be a better way to go. Something like:

open ... or do { ... };
[download]

With the do determining more specific messages: "Directory was not supplied"; "File specified does not exist"; and so on.

If users get a specific message, it may indicate something they can fix themselves, especially if it's a simple typo; e.g. file parameter supplied as file.tx but should be file.txt. When presented with a generic message, users may not be able to investigate themselves and may, unfortunately, provide the oft seen error report: "It didn't work".

— Ken

Comment on Re^2: Testing unexpected I/O failures Select or Download Code

Replies are listed 'Best First'.

Re^3: Testing unexpected I/O failures
by Fletch (Bishop) on Nov 25, 2020 at 14:31 UTC

The idiom I've normally used is more along the lines of something like this; call open then use constants from Errno to figure out from !$ what specifically went wrong and give more detailed advice. You can also use a variation on this to (e.g.) try and open a file for reading and fall back to another default location if !$ == ENOENT because it didn't exist; (EDIT) or you don't care if it didn't exist, but other errors you do want to bring to the user's attention.

use Errno qw( :POSIX );
use Log::Log4perl;

## ...
if( open( my $fh, q{<}, $filename ) ) {
  my $frobulated_data = {};

  ## process with $fh

  close( $fh );
  return $frobulated_data;
} else {
  if( $! == ENOENT ) {
    ERROR( qq{Couldn't find file '$filename': $!} );
  } elsif( $! == EACCES ) {
    ERROR( qq{Problems with permissions for '$filename': $!} );
  } elsif( ## whatever else specific you want to handle ... ) { #...
  } else {
    ERROR( qq{Problem opening '$filename': $!} );
  }
  return;
}
[download]

The cake is a lie.
The cake is a lie.
The cake is a lie.

[reply]
[d/l]
[select]


Don't ask to ask, just ask
	PerlMonks