Re: Using die() in methods

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;
}
[download]

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

toby döt ink

Comment on Re: Using die() in methods Select or Download Code

Replies are listed 'Best First'.
Re^2: Using die() in methods by v_melnik (Scribe) on Jul 07, 2014 at 18:23 UTC
Oh, yes, that's exactly why I use die() only in object-builders, because I have a habit to new() through eval(). I've got this habit, because a certain number of other people's classes sometimes could die() in the builder(). But I think the descision to die() can have only the main module. Subroutines call other subroutine, if someone have an error occuried - okay, let them to return the special sign to the caller and the caller will report to its' caller and so on - until the process pop up to the main module. And the main module sends the long error message to the error stream: "Can't sub1(): Can't sub2(): Can't sub3(): Can't open connect to the database: ...". I've made a tricky Error-class for my own usage. It has the method error(), when I call it with some parameter, it stores this parameter as the error message and returns undef, so I can do return($self->error("Something bad has happened")) and the caller will get undef. When it gets the undef value, it checks for $caller->has_error(). So I can be sure whenever the method has got an error or it just doesn't find any records in the database. It's not worse than try/catch, but it let other people to call methods of my classes without being afraid to die(). V.Melnik	[reply]
Re^3: Using die() in methods by tobyink (Canon) on Jul 09, 2014 at 22:33 UTC
You wrote: "okay, let them to return the special sign to the caller and the caller will report to its' caller and so on - until the process pop up to the main module." But perhaps you might have said instead: "let them to return the special sign to the caller and the caller will report to its' caller and so on - until it reaches a level I forgot to check for the special sign." Exceptions are a special sign. But they are a special sign that you cannot forget to pass to your caller because Perl automatically passes it up and up and up until it finds a caller that is willing to do something useful with the special sign (i.e. catch the exception). So throw exceptions! Don't return special signs! If every level of caller needs knowledge about your "special signs", then your callers have too much knowledge about your class. Your callers have become tightly coupled to your class. This is bad. "But I think the descision to die() can have only the main module." I think you're confusing the decision to `die()` with the decision to `exit()`. I absolutely agree that the main script should be making the decision about when it exits. However, as you know, calling `die()` does not necessarily cause the script to exit; it can be caught by any level of caller and handled gracefully. It only causes the script to exit if an error occurs that nothing is able to handle. toby döt ink	[reply] [d/l] [select]
Re^3: Using die() in methods by boftx (Deacon) on Jul 08, 2014 at 02:37 UTC
Do not fear death, you will re-awaken to a world built with Perfect Perl 7 and no Python. You must always remember that the primary goal is to *drain the swamp* even when you are hip-deep in alligators.	[reply]