Question, as it has come up in this thread twice, and that is the issue of die() vs exit((). The Camel states that one should not exit a subroutine when an error needs to be trapped. But if not, is die necessary, or is exit sufficient?

Comments?


—Brad
"The important work of moving the world forward does not wait to be done by perfect men." George Eliot

What the Camel does or doesn't say is mostly irrelevant. If your coding standards allow for exit() within a subroutine, then use it. However, most of the community has come to expect die() within subroutines and exit() (if it's even used) from the main scope.

Now, die() and exit() do different things. The biggest difference is

eval {
    print "Inside\n";
    die;
};
print "Outside\n";
----
Inside
Outside
[download]

vs.

eval {
    print "Inside\n";
    exit;
};
print "Outside\n";
----
Inside
[download]

exit() exits, end of story. die() allows for some manner of error trapping. This is the main reason why die() is preferred within subroutines. You may want to reuse that subroutine somewhere else that wants to be able to trap the abnormal termination. Also, die() triggers $SIG{DIE}, which can also be useful to trap.

---

My wife's blog

I would say not, for one thing it limits the possibility of reuse in your code if you are to issue the untrappable exit() in your subroutine.

/J\

Personally I would always prefer to exit the program from within the main program rather than a sub-routine, of course you can't always achieve this due to exception conditions that may occur in the sub-routines (well you could if you were to wrap the whole of the program in a block eval - thus achieving a single point of exit.)

If nothing else it makes maintenance easier if there is only once logical point of exit from the program and that is easily visible within the main body of the code. This becomes more difficult with event driven programming (such as with a GUI or such-like) but it is still possible.

We are relatively lucky with languages such as Perl inasmuch as they will clean up all committed resources on program exit - but there have been systems where it was often a fatal mistake to exit the program without closing open filehandles or free allocated memory, but I would still consider it good practice to control the program flow in such a way that you are in a position to release resources where necessary.

(BTW you nearly got a whole spam e-mail instead of this - I pasted into the comment box rather than the spamcop text area and hit submit before I realised what I had done - more coffee needed.)

/J\

You'll also want to catch and examine those dies in your tests.

I don't see any problem with exiting from within a subroutine, no matter how deep, if it makes sense. I do, however, see a problem in using the & sigil when you don't need it. It confuses me into wondering what do_task is, when it's just a normal perl subroutine (as opposed to a reference, or a sub with a prototype (which I would wonder what the prototype was) or ...). The visual clue I use for calling functions is the parentheses. The & is only there when it needs to be - it's a good visual clue that something abnormal is going on.

I could definitely see exiting from just any old sub being a problem in larger projects.

my $result = do_task();
exit() if ($result eq 'exit');

sub do_task {
    ... do something...
   if ($somecondition) {
       return 'exit';
   }
}
[download]

You know, that article is WAY overused. Remember that it came from a time when people were using line-numbered gotos and creating contstructs (loops) from gotos. My personal (and somewhat informed) opinion is that sometimes a labeled goto can simplify a loop exit in such a manner that one line could replace many conditionals. In the case where a goto replaces multiple conditionals inside a loop, this not only makes the code more readable but it can also make the code run exponentially faster (conditionals take clock cycles). The article you referenced is about people abusing the goto and the need for more friendly/readable constructs that would help make more maintainable code. If the occasional goto helps move more to that end, then use it.

Exponentially faster? Only if your code isn't actually doing anything other than test exit conditions inside that loop, I'd think. The maintainability benefit, on the other hand, is gigantic, though I'd use Perl's last LABEL; construct (with a label on the outer loop) rather than a literal goto (I personally find this a much tidier mechanism, though I realize that they're fundamentally pretty much equivalent).

And not, of course, that I would disagree with the statement that both that article headline in particular (usually without the link) and "$foo considered harmful" in general are employed in many places where they probably shouldn't be—just wanted to throw in some minor quibbles on the specifics.




---

If God had meant us to fly, he would *never* have given us the railroads.
    --Michael Flanders