in reply to How portable are common $! error codes?

In my opinion, the $! is for the end-user's edification, and that's all. Do not assume you can find a certain substring inside. Do not assume that it's a certain number.

If you have to verify that something had the right result, then verify the result itself, not the feedback. Maybe something didn't set the feedback variables at all, but failed anyway.

In Eiffel, you code by contract. You start a routine with a check that the input situation must comply with a given test. You then perform the work. You end the routine with another check that the new situation must comply with another test to be sure the work was done. This is Just like the old saw about public speaking, "first you say what you're about to say, then you say what you came to say, then you say what you just said."

Update: Coding by contract's fine in Eiffel, but a bit overkill in most Perlish circumstances. You usually don't need to second-guess the actual Perl return values, but you shouldn't assume that feedback (like $!) will be more useful than the basic return values. Double-test the results and fail only when it's critical that you either succeed or stop.

--
[ e d @ h a l l e y . c c ]

  • Comment on Re: How portable are common $! error codes?

Replies are listed 'Best First'.
Re: Re: How portable are common $! error codes?
by Anonymous Monk on Apr 23, 2003 at 21:18 UTC
    >If you have to verify that something had the right result, then
    >verify the result itself

    Hmm.. perl doesn't make this easy though.

    open() returns undef on failure, that's it.

    Now that's not terribly useful - I have to treat a non-existant file separately to other errors, so I either have to check $! or test -f without introducing a race condition.

    Ok, so I could go to something like this: 

    
  use Errno;

  unless ( open(INFILE, "<", $filename) )
  {
    return if exists &Errno::ENOENT && $! + 0 == &Errno::ENOENT;
    return unless -f $filename;

    die "open failed: $!";
  }
    Not great, but more portable. Makes use of Errno::ENOENT if its available but fallbacks to a simple -f as a last resort.

    So, any suggestions for improvements???

[reply]
      Hmm, perhaps I'll just change -f to -e while nobody's looking :)
[reply]
        If you are going to read it, check for that explicitly with '-r' rather than something like -f or -e.
[reply]
      If you're testing with -f, then (and you mentioned it) shouldn't you just combine that with the -e test? Like: 
      
if ( -e $file ) { #file exists
  if ( -f $file ) { #file is also plain
    do_your_thing();
   }
  else {
    special_error_handler_for_non_plain_files();
   }
}
else { #file doesn't exist
  special_error_handler_for_nonexistent_files();
}

      [download]
      I know, a bit simplistic, but just throwing the idea out there for ya. YMMV.

      Theodore Charles III
      Network Administrator
      Los Angeles Senior High
      email->secon_kun@hotmail.com
      perl -e "map{print++$_}split//,Mdbnr;"
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom