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

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Journal of ambs (3914)

Thursday February 11, 2010
11:57 AM

What is the status of $@?

[ #40175 ]

Accordingly with the perlvar manpage, $@ is used for error messages produced by eval.

I would like to use it as a more general variable for error messages. When a function returns a string, there isn't much that can be done to return a error string. Probably returning a list, setting an object, nothing clean and simple as real perl code :)

What I want is to use $@. The function will return undef and set $@ to the error message. This is clean enough and should work.

But I have some doubts: is there any problem on using this approach? In the function I probably need to clean up $@ and assign undef to it?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • My good man, you want Exception::Class [p3rl.org] and an evening spent together with Chapter 13 of PBP.
  • 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
  • ... 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