NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

use Perl

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Without JavaScript enabled, you might want to use the classic discussion system instead. If you login, you can remember this preference.

Re: What is the status of $@? (Score:1)

by daxim (8218)

My good man, you want Exception::Class [p3rl.org] and an evening spent together with Chapter 13 of PBP.
also.. (Score:2)

by domm (4030)

http://domm.plix.at/talks/die_perl_die.html [domm.plix.at]
don't do that (Score:1)

by rjbs (4671)

Like the other said, use die.
Also, consider using Try::Tiny to replace eval. It's a very small, VERY helpful tweak to how eval works.
I have seen exactly one library on the CPAN that uses the "return undef and set $@" pattern. It is bizarre and annoying, and not like anything else. When I mentioned it to a coworker, he sputtered and said something like, "WHY WOULD THEY DO THAT???"
Don't be that guy!

--
rjbs
Sure it works... (Score:1)

by janus (3624)

... and is all just a question of the API.
No single argument against using $@ is really addressing this important
point. Most alternatives are just eval flavors, which in turn return an
undefined value and set $@, so i don't count those as different.
Others provide new features, come with overhead but solve no new problem.
But in the end we're just talking about different error handling APIs...
and i like the Perl builtin way too :-).
Simon