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?
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!
... 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
