Front page | perl.perl5.porters |
Postings from June 2008
On Mon, Jun 9, 2008 at 1:11 AM, Dr.Ruud <rvtol+news@isolution.nl> wrote:
> "Joshua ben Jore" schreef:
>
>> Semi-recently at work I found that a few buggy exception objects in
>> the global $@ were clearing themselves out of $@ as a side effect of
>> examining them for truth.
>
> Oops, I'd better change my
>
> push @errors, $@ if $@;
>
> to something like
>
> {my $e; push @errors, $e if $e = $@}
No, that's only if you have exception objects which might also have
overloading. Also, you can only trust $@ as long as you also trust
that you'll never have objects around that can clear $@ during their
DESTROY phase. The presence of objects which can set $@ during their
DESTROY means your evail{} can fail and $@ can be empty afterwards.
It's why you have to actually return something from eval or assign
success out somewhere.
For "95%" of perl code, trusting that $@ is an ok boolean works. For
the other 5%, set phasers to kill and raise all shields.
my $ok = eval { ...; return 1};
unless( $ok ) {
my $e = $@;
...
}
Which is as careful as I think I know how to be WRT to perl's
occasionally evaporating exceptions. It uses the real success/failure
condition of eval{} and then copies out of $@ prior to doing anything
with it. Of course, my perl is now verbose. I wish for my new Perl 6
overlords which I assume makes this succinct again.
I also worry occasionally that the '1' in 'return 1' has been upgraded
to an object and looking at it might invoke overloading which can
clobber $@. Further, I worry about objects in $@ which are boolean
false. Even more paranoid, I worry about tied $@.
Josh
Thread Previous
|
Thread Next