Is it bad to use "return" to exit a method?

[Maximilian]

like for example

try 
       {
           doThings();
       } 
       catch (ParseException ex)
       {
           System.out.println("Its not working :(");
           return;
       }

I think its more readable that doing say the whole method in a try catch or having nested try catches no? Is it bad practice?

 

[nickbits]

Assuming doThings is generally about parsing, I think that is fine.

However, having catches that just print out the error and do nothing is bad. You need to propagate the error and inform the user or take some action.

 

[MrChad]

System.out.println is pretty bad as well. Use a library like log4j for logging errors so that you can configure log output without changing your code.

 

[Maximilian]

Yeah i just stuck the println as an example, im more interested in the implications of exiting early through a return.

I only learned you could use a return that way recently and thought it was pretty handy.

 

[irishScott]

Yeah i just stuck the println as an example, im more interested in the implications of exiting early through a return.

I only learned you could use a return that way recently and thought it was pretty handy.

Indeed it is. In fact it's quite common to check for argument validity that way.

ie:

public void someFunction(Object argThatShouldntBeNull) {
    if(argThatShouldntBeNull == null)  {
        //Print error message and/or return error value, and all that good stuff here
        return;
    }

    //Proceed with normal function operation

}

 

[Markbnj]

Indeed it is. In fact it's quite common to check for argument validity that way.

ie:

public void someFunction(Object argThatShouldntBeNull) {
    if(argThatShouldntBeNull == null)  {
        //Print error message and/or return error value, and all that good stuff here
        return;
    }

    //Proceed with normal function operation

}

I would be more likely to throw an exception in that case, but yeah. Returning from the middle of a function was something I had to slowly get used to over the years. Now it's become an accepted practice.

 

[Schmide]

Indeed it is. In fact it's quite common to check for argument validity that way.

ie:

public void someFunction(Object argThatShouldntBeNull) {
    if(argThatShouldntBeNull == null)  {
        //Print error message and/or return error value, and all that good stuff here
        return;
    }

    //Proceed with normal function operation

}

Being a bit nit-picky. The above could be a bit hazardous if the Object doesn't provide operator overloading for ==. Since the object is passed on the stack it could never be null but could be invalid.

 

[irishScott]

I would be more likely to throw an exception in that case, but yeah. Returning from the middle of a function was something I had to slowly get used to over the years. Now it's become an accepted practice.

Being a bit nit-picky. The above could be a bit hazardous if the Object doesn't provide operator overloading for ==. Since the object is passed on the stack it could never be null but could be invalid.

It's pseudo-code guys lol.

Next time I'll do it in c++ and include printing to cerr along with setting the appropriate errno value.

 

[Tweak155]

It's pseudo-code guys lol.

Next time I'll do it in c++ and include printing to cerr along with setting the appropriate errno value.

Please provide a version number as well.

 

[KB]

I think using return in a catch statement is bad practice. I usually allow the exception to cascade up the call stack so that each function that calls your function also stops executing. If you use return, calling functions may think the function was successful and then try their own further processing, putting everything in an inconsistent state.

I am OK with a return after doThings, but not usually in a catch.

 

[BrightCandle]

In the imperative programming world its normally neater to use a return to exit out of a method given some condition or exceptional circumstance. Its neater because the scope of the if statement or catch doesn't get large and cover the rest of the code purely as a guard. However that does not mean its good practice. Another way to do this is to take all that bit chunk of code and move it out into another method, thus avoiding the return statement as the method itself focusses specifically on the error condition.

In the functional world if's and try's etc typically return a value and so you don't return anymore you just result in some value, and I suspect that in the end this is a more reliable way to handle the situation in a clean way. Its also possible to provide a function that holds a default value such that if the function called does exception that the default is provided instead of the value from the function.

So return statements I think are a necessary evil but I would personally think a more value based approach is less prone to errors.