|
Re: canonical doc explaing need for "eval { ... } or do {...}" construct
by pryrt (Abbot) on May 09, 2022 at 13:52 UTC
|
according to my bookmark, Bug in eval in pre-5.14 shows an example of the bug in practice, and provides a link to perl514delta, directing you to the sections on $@, which explain that prior to 5.14, $@ could be clobbered. I don't know if that's sufficient enough for you and your colleagues.
addendum: that conversation also has an anonymonk-link to a couple of rt issues with verbiage that says it's still dangerous even after 5.14's improvements. | [reply]
[d/l]
[select] |
Re: canonical doc explaing need for "eval { ... } or do {...}" construct
by karlgoethebier (Abbot) on May 10, 2022 at 11:05 UTC
|
| [reply] |
Re: canonical doc explaing need for "eval { ... } or do {...}" construct
by Discipulus (Canon) on May 10, 2022 at 11:08 UTC
|
Hello LanX,
it is already linked, but for me this by them is canonical enough for me :)
Lamentably our docs are at least suboptimal: why dont you fork perldoc and add a paragraph in eval ? I'm sure you can phrase it correctly.
After the PR you can point your collegues to standard documentation.
L*
There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
| [reply]
[d/l] |
|
|
Thank you all! :)
I think the overall best solution is to mention Try::Tiny in the perldocs.
eval { ...; 1 } or do {...} might be a good solution if you hate dependencies and want backwards compatibility.
But it's just too much boilerplate to keep in mind.
Me too, I forgot about the ;1 part when starting this thread.
But I'm worried about compatibility issues with Try::Tiny and the new try feature in 5.36.
| [reply]
[d/l]
[select] |
|
|
| [reply] |
|
|
I think the overall best solution is to mention Try::Tiny in the perldocs.
hmmm, the Perl docs probably should be in the business of recommending specific non-core modules.
Especially since Perl is getting a try keyword...
| [reply]
[d/l] |
|
|
|
|
|
Re: canonical doc explaing need for "eval { ... } or do {...}" construct
by cavac (Parson) on May 10, 2022 at 07:57 UTC
|
Personally, i usually use something like this:
use English;
...
my $evalok = 0;
eval {
SOME_RISKY_CODE
$evalok = 1;
};
if(!$evalok) {
print "Something bad happened: ", $EVAL_ERROR, "\n";
work_around_the_problem_or_give_up();
}
This may be a good or bad solution. But at least for me, it makes it easier and faster to visually scan the code later in its life cycle and see how it's meant to flow and if there is error handling in place.
perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'
| [reply]
[d/l]
[select] |
Re: canonical doc explaing need for "eval { ... } or do {...}" construct
by eyepopslikeamosquito (Archbishop) on May 10, 2022 at 10:37 UTC
|
| [reply] |
Re: canonical doc explaing need for "eval { ... } or do {...}" construct
by ikegami (Patriarch) on May 11, 2022 at 14:18 UTC
|
Since 5.28, it doesn't matter.
Before, especially before 5.14, $@ could get clobbered, so if eval { ... ; 1 } was more reliable.
There was a time where it was possible for $@ to get cleared or replaced before eval returned.
package Mod { DESTROY { eval { } } }
eval {
my $x = bless( {}, "Mod" );
die( "xxx\n" );
};
print $@ || "[undef]\n";
$ 5.12t/bin/perl a.pl
[undef]
This has been fixed.
$ 5.14t/bin/perl a.pl
xxx
So, using eval { ...; 1 } and checking the result of eval was more reliable. And it was promoted as the more reliable solution for this reason. There was an attempt to fix in 5.14, but edge cases were only fixed in 5.28.
Updated to cover edge cases found later, as per choroba's reply.
| [reply]
[d/l]
[select] |
|
|
| [reply]
[d/l] |
|
|
| [reply] |
Re: canonical doc explaing need for "eval { ... } or do {...}" construct
by Anonymous Monk on May 10, 2022 at 07:25 UTC
|
| [reply] |
|
|
| [reply] |
