At 01:32 AM 8/25/00 +0200, Bart Lateur wrote:
>On Thu, 24 Aug 2000 13:50:56 -0700, Peter Scott wrote:
> >Yes, this is losing information; the former $! is no longer around. I
> >contend that it's eliding functionality that is seldom, if ever, used, in
> >favor of a natural simplification. There's one place where an error
> >message shows up. One. No need to figure out what kind of thing failed.
>
>There's a whole in your logic.
>
> eval {
> open "some_name_for_a_file_that_does_not_exist";
> undef;
> }
>The eval will not fail ($@ not set), but $! will be set to something
>like "file not found".
>
> eval {
> open "some_name_for_a_file_that_does_not_exist"
> or die "Hoorible death: $!";
> }
>
>Now, as it is now, $@ *will be set, to the complete error message. $!
>will be set, too.
>
>$@ is *the* marker that something died inside the eval. You can't test
>eval's return value: both examples return undef. $! is unreliable --
>unless you're proposing that $! would be cleared at the end of the eval
>block, if it doesn't fail (as is pretty much the case with $@ now).
Remember, the proposal is to make all these variables the same one. It's
hard to talk about because when we say $@ or $! it's not clear whether we
mean the current one or the new one. Let's say that the new variable is
going to be $! and I'm just going to describe the proposed new
operation. Here's what happens in your examples:
eval {
open "some_name_for_a_file_that_does_not_exist";
# $! set to "file or directory does not exist"
undef;
}
# $! set to "" (or undef, whichever makes more sense) on
# eval block termination since no exception was thrown
This makes sense because the programmer intentionally cleared the error
indication by using a non-exception-throwing system call (open). This is
the behavior they should expect. If they C<use Fatal> then open will die,
the eval block will exit and $! will be set to "no such file or directory".
eval {
open "some_name_for_a_file_that_does_not_exist"
# $! set to "no such file or directory"
or die "Hoorible death: $!";
# $! set to "Hoorible death: no such file or directory"
}
# $! eq "Hoorible death: no such file or directory"
This also makes sense because the error message is what was explicitly
coded inside the eval block. There isn't another error variable set at
this point and there never was.
Now, does the programmer need to know something died inside the eval? If
so, they can use the RFC 88 mechanism (which will have to be based on
something a bit more fundamental than just checking $! at block exits). If
not - and many won't care - then they've got what they want - the error
message.
--
Peter Scott
Pacific Systems Design Technologies
