Question

I sometimes have colleagues frowning about using the return statement to leave a routine (before the end) because it looks like a kind of hidden goto and all gotos are evil. I neither share the thought about a goto being bad no matter how used nor can I really see why using return like this is so bad.

The question is relatively language independent. I currently program in PL/SQL and Objective-C so I give examples in this languages.

Objective-C

-(void)finishedLoading:(NSString*)result success:(BOOL)success 
{
    NSLog(@"delegate method finished loading invoked");   
    if (!success) {
        self.status.text = @"Failed to load file.";
        return; // IS THIS BAD??
    }

    self.status.text = @"File loaded.";

    // do more stuff here with result string
}

PL/SQL

PROCEDURE example(i_parameter pls_integer)
AS
BEGIN
   IF i_parameter IS NULL THEN
      RETURN; -- is this bad??
   END IF;

   -- do more stuff here

END example;

The examples are really only examples and maybe they can be criticized as they are, but I rather would like to know why the return should not be done. The only alternative that I see is to have a routine wide embracing if statement with potentially nested ifs making it hard to read but some people prefer that and I never figured out why.

Answer 1

I think it’s fine. In fact, I try to do all my validation at the top, either throwing or returning as necessary before the ‘meat’ of the method. Keeps things simpler with fewer nested-if/else’s, etc. Also easier to unit-test with fewer code-paths to cover.