|
Re: How portable are common $! error codes?
by halley (Prior) on Apr 23, 2003 at 19:20 UTC
|
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 ]
| [reply] |
|
|
>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'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();
}
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] |
Re: How portable are common $! error codes?
by Thelonius (Priest) on Apr 23, 2003 at 19:22 UTC
|
If you use Errno;, then you can use symbolic constants such as ENOENT for 2. This is a little more portable than using the actual numbers, but the constants are not guaranteed to be defined except on POSIX systems. You can see the current list of POSIX error constants at http://www.opengroup.org/onlinepubs/007904975/basedefs/errno.h.html.
| [reply]
[d/l] |
Re: How portable are common $! error codes?
by chromatic (Archbishop) on Apr 23, 2003 at 19:49 UTC
|
perl.h pulls in errno.h, which is probably what you want. You might also look at Errno.pm and how it's built. You really oughtn't rely on the numbers being portable, however.
| [reply]
[d/l]
[select] |
Re: How portable are common $! error codes?
by Jenda (Abbot) on Apr 23, 2003 at 20:51 UTC
|
unless ( open INFILE, "<", $file )
{
return unless -f $file;
die "open failed: $!";
}
Of course it's possible that you will not print the error message if someone removes the file between the open() and the -f. Don't know if that matters to you.
Jenda
Always code as if the guy who ends up maintaining your code
will be a violent psychopath who knows where you live.
-- Rick Osborne
Edit by castaway: Closed small tag in signature | [reply]
[d/l]
[select] |
Re: How portable are common $! error codes?
by PodMaster (Abbot) on Apr 24, 2003 at 06:35 UTC
|
I'd like to quote from `perldoc perlop':
Binary ``=='' returns true if the left argument is numerically equal to the right argument.
No need for that +0 nonsense.
MJD says you
can't just make shit up and expect the computer to know what you mean, retardo!
I run a Win32 PPM
repository for perl 5.6x+5.8x. I take requests.
** The Third rule of perl club is a statement of fact: pod is sexy.
|
| [reply] |
|
|
| [reply] |
Re: How portable are common $! error codes?
by crenz (Priest) on Apr 23, 2003 at 21:28 UTC
|
Most of the time, it is enough to just output the error message in $! to the user, so they can figure out what's happening. If you want to find out more about the exact condition, I'd suggest you use the -X operators, e.g.
die "Can't read $_" unless -r;
die "Can't write $_" unless -r;
die "Can't execute $_" unless -x;
die "$_ not a file" unless -f;
die "$_ not a directory" unless -d;
# ...
| [reply]
[d/l] |
|
|
Note, if you call lots of -X operators in succession (i.e. for the same $_), you can use the special filehandle of a single underline to avoid repeating the stat(2) system call:
die "Can't read $_" unless -r;
die "Can't write $_" unless -w _;
die "Can't execute $_" unless -x _;
die "$_ not a file" unless -f _;
die "$_ not a directory" unless -d _;
| [reply]
[d/l] |
Re: How portable are common $! error codes?
by Anonymous Monk on Apr 23, 2003 at 21:24 UTC
|
| [reply] |