in reply to Using die() in methods

My general approach is to die when the error is unlikely to be recoverable from, such as a coding error (i.e. missing or invalid parameters, etc.) and to return undef if it is something like a record does not exist. You can find several examples of this in modules on CPAN.

You must always remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.

Replies are listed 'Best First'.
Re^2: Using die() in methods
by Laurent_R (Canon) on Jul 06, 2014 at 20:27 UTC
    Yes, that sounds like a rather reasonable approach to the problem. One thing I really dislike about some languages, such as PL/SQL for example, is the way they throw an error when no data is found, where it would be perfectly legitimate to use a select statement to see if a record exists and then, depending on the result, to either create a new record or to update an existing one. Of course, the exception can be trapped, for example by using a separate procedure with an exception-catching mechanism, but it makes the flow of the program much more complicated with very little benefit. This is a bit as if you had to use eval every time you need to check if a hash value exists or is defined.

    Failing on an outright error (such as invalid parameter) and returning undef (or some other specific status) when no data is found is much more reasonable.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom