On Thu, 24 Aug 2000 17:57:55 -0700, Peter Scott wrote:
>>I've read 151 a few times, and I don't understand how it can impact
>>the implementation of RFC 88 as a module. Please explain.
>
>If $@ and $! are merged, then in code like
>
> try {
> system_call_that_fails();
> more_stuff_that_succeeds();
> }
> finally {
> }
>
>does the finally block think there is a current exception or not? $! was
>set by the failed system call, but nothing died or threw. If $@ is put
>into $! instead, how does the finally block know that it's not an
>exception?
You're citing my objection for merging in $@ with the rest of the error
variables. $@ currently is the "eval failed" flag, irrespective of what
else failed. We *must* have such a flag. If $@ and $! would be merged,
$! will have to be cleared if the eval doesn't fail, just like $@ is
now. Er, is it?
eval {
eval "oops this isn't perl";
print $@;
print "It's ok!\n";
};
print "Error message: \"$@\"\n";
-->
Can't locate object method "t" via package "isn::t" at (eval 1) line 1.
It's ok!
Error message: ""
Yup, apparently it is. So, if $! and $@were to be merged, $! would have
to be cleared to if the wasn't a fatal error in the try block.
--
Bart.
