Generally speaking, you should die (or ExceptionClass->throw, or Carp::croak, or Carp::confess... which are all just wrappers for die) to indicate an error condition.
Why? Because when people are using your objects like this:
my $result = $object->do_something; if (not $result) { warn $object->last_error; }
... then you're heading for a situation where in order to get sensible behaviour from your object, people are needing to call multiple methods on it in a particular order, and do stuff with the results. The order in which the methods must be called should be considered one of your class' implementation details. And when one of your class' implementation details is being implemented by the caller, this goes against the principle of encapsulation — all your class' implementation details are supposed to be implemented within your class.
Of course, you need to think about what you consider to be a true "error condition". If you're asked to look up an employee ID, and a database handle hasn't been provided, this is probably an error and you should die. If you're asked to look up an employee ID, and there is no current employee with that ID, it's less clear whether the sensible behaviour would be to die or return undef.
In reply to Re: Using die() in methods
by tobyink
in thread Using die() in methods
by v_melnik
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |