Sending Out Functions To Return Or To Die

Question

Which is preferable for both solid technique and secure coding?

Example #1:

function_one()
    blah;
    function_two()
        blah;
        print blah;
        exit;

...

Example #2:

function_one()
    blah;
    function_two()
        blah;
        return blah;
    return blah;
print blah;

Obviously this is a simplified version, and I am looking for an answer which is universal for larger function trees, if possible.

-1: I liked Example #1 because it seemed faster to terminate as soon as it is done doing what it does, instead of returning to the original call to lives out its natural life. Also, Example #1 seems to compartmentalize code, helping to prevent unintended code from executing further on down (which should be detected during testing, but I prepare for the worst). However, this model has proven difficult to maintain, and doesn't seem to scale well. For instance, I had a web page which I wrote to echo out what it was supposed to and then terminate, but this caused problems down the road with making sure that the http headers were inserted before the output; this would require sending the headers as a function parameter.

-2: Example #2 seems to maintain a standard order of doing things because not all functions will terminate as soon as possible. Also code can be combined easier without passing additional parameters as in Example #1. However, Example #2 requires more return statements, and will continue out the rest of the program. What do you think?

@KilianFoth Thank you, I was just leaving a note to have someone help me fix the indentations. I tried using the 4-spaces method suggested in the advanced help for the editor, but it didn't show up correctly... But you got them right. — user58446, Dec 19 '14 at 13:55
See also [Structured programming](http://en.wikipedia.org/wiki/Structured_programming), especially the bit about 'early exit' — Dan Pichelman, Dec 19 '14 at 14:03
@DanPichelman The main objection is that you may need to do cleanup actions, which is solved by using `finally`. The bigger problem here is a function trying to abort *the whole program* instead of just aborting itself and letting something higher up figure out what to do. If a program tries to exit without the user requesting it I expect it to be deeply, incredibly, irrevocably broken; so broken that you wouldn't even be able to attempt to present an error message to the user. — Doval, Dec 19 '14 at 14:17
question is rather [unclear](http://meta.programmers.stackexchange.com/questions/6483/why-was-my-question-closed-or-down-voted/6489#64890) but if I understand correctly, first example seems to be more for [tag:exception]al cases, see eg [Defensive Programming vs Exception Handling?](http://programmers.stackexchange.com/q/139171/31260) and [I've been told that Exceptions should only be used in exceptional cases. How do I know if my case is exceptional?](http://programmers.stackexchange.com/q/184654/31260) — gnat, Dec 19 '14 at 15:08
@gnat Perhaps I should have stipulated that this problem was conceived with a webpage script in mind: so the idea was that once the webpage had been echoed out, I wanted to exit ASAP to prevent whatever I hadn't thought of... this was the defenseive part. However, this logic may be applicable to other dead-end type scripts... but see additional comments. — user58446, Dec 20 '14 at 15:17
@DanPichelman Your link regarding the problems arising from early exits is part of what I was looking for and hadn't considered... That and to be told the true answer lies in better code structring (Doval). — user58446, Dec 20 '14 at 15:19

score 7 · Accepted Answer · answered Dec 19 '14 at 14:00

In general, you should avoid exiting your entire program from random functions. Why?

It makes your code hard to read. The function in question becomes difficult because you then need to care about what context it's being called from. The rest of the program becomes difficult because the "normal" exit point isn't correct all the time.
It makes that code less reusable. Just because you consider that a fatal error (with a certain message) doesn't mean that is the end of other programs.
It makes that code hard to unit test. Depending on the language, it may be impossible to unit test.

There are certainly cases where it can make sense - global exception handlers which clean up before dying, for example. But in general, just return or throw.

Sending Out Functions To Return Or To Die

1 Answers1