develooper Front page | perl.perl5.porters | Postings from June 2008

Re: Fatal/autodie exception hierarchies for Perl 5

Thread Previous | Thread Next
Joshua ben Jore
June 9, 2008 07:51
Re: Fatal/autodie exception hierarchies for Perl 5
Message ID:
On Mon, Jun 9, 2008 at 1:11 AM, Dr.Ruud <> 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 $@.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About