Chas. Owens schreef:
> Dr.Ruud:
>> I never understood why checking $@ is done, when checking the eval
>> return value itself is available (and it always is, or can be made
>> so).
>>
>> eval {
>> ...
>> 1;
>> } or do {
>> ...
>> };
>>
>> The $@ can be set in many ways. Some coders even test $@ with
>> regexes. Let's try to get rid of all that, just as with bareword
>> filehandles and 2-argument opens.
>
> Um, what sets $@ besides eval?
Another (concurrent) eval. But see also the groups.google link below.
The value of $@ is more distant than the return value of eval, so why
would one ever want to use the first in stead of the last?
Further, there is a risk that $@ gets clobbered, so why even want to run
that risk at all?
> If you have code that is setting $@ then you have bad code;
eval sets [EMAIL PROTECTED] Not all code that uses eval, is bad code.
;-)
I don't think this is inside your box either:
http://www.google.com/codesearch?q=%22local+%24%40%22&hl=en&btnG=Search+Code
finds plenty of popular modules that set (a localized) $@, to protect
the outer [EMAIL PROTECTED]
> if your if (or given, see below) is right
> next to an eval, then there is no way* for it to be set other than by
> that eval:
Yes, there is: evals can happen to run "intertwined".
> The $@ variable is not just used for checking to see if an error
> occurred; that isn't even its primary purpose. Its reason for
> existing is that it holds the error that actually occurred.
Nothing in the "eval{...;1} or do{...};" construct prevents you from
inspecting $@ inside the do{}. So it beats me why you even mention the
possibility, $@ holds important information (like a string, or a
reference to error information); not using that would be very stupid.
> If you are already going to [test [EMAIL PROTECTED] why not go ahead and use
> $@ to detect that an error occurred at all?
Because testing $@ is simply less accurate than testing the return value
of eval. Why choose the next best thing, if the best is also there?
> * Well, theoretically a signal handler could be called in the brief
> span of time between the eval and the if and $@ could be set, but not
> only is highly unlikely, it is also bad practice to be calling an eval
> (or doing anything non-trival for that matter) in a signal handler.
In production code such "coincidences" happen.
Check `perldoc -f alarm` which mentions "unexpected errors" and that the
"\n" is required.
See also
http://groups.google.com/group/perl.perl5.porters/browse_thread/thread/2f41b209944dbb2f
and
http://www.nntp.perl.org/group/perl.perl5.porters/2007/07/msg127087.html
which is about (a non-localized) $!.
Hey, I never said it is easy to create code that breaks under
"eval{};if($@){...}" and works OK under "eval{...;1} or do{...};".
--
Affijn, Ruud
"Gewoon is een tijger."
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
