On Thu, 24 Aug 2000 13:50:56 -0700, Peter Scott wrote:
>>But $@ is an entirley different beast.
>The proposal is that $! would be overwritten with the die string. Reason:
>whoever's interested in both $@ and $! at the end of an eval? There was an
>error; everyone looks at $@, which almost certainly contains $! if it was
>useful. So the above becomes:
>
> eval {
> open ",^#!" or die "Cannot open file: $!"
> };
> print $!; # Contains the user provided string etc
>
>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).
--
Bart.
