0

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
  • 1
    See also 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
  • @Doval Agreed (100%) – Dan Pichelman Dec 19 '14 at 14:29
  • question is rather unclear but if I understand correctly, first example seems to be more for exceptional cases, see eg Defensive Programming vs Exception Handling? and I've been told that Exceptions should only be used in exceptional cases. How do I know if my case is exceptional? – gnat Dec 19 '14 at 15:08
7

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.