78

Is it wrong to have a return statement in a catch block? What are the alternatives?
i.e:

public bool SomeFunction()
{
    try
    {
        //somecode
        return true;
    }
    catch(Exception ex)
    {
        MessageBox.Show(ex.message);
        return false;
    }
    
}
Selim Yildiz
  • 5,254
  • 6
  • 18
  • 28
lowlyintern
  • 789
  • 1
  • 5
  • 3
  • See also: http://stackoverflow.com/questions/2373560/return-statements-in-catch-blocks, http://stackoverflow.com/questions/449099/is-it-bad-practice-to-return-from-within-a-try-catch-finally-block, http://stackoverflow.com/questions/1713388/in-the-try-catch-block-is-it-bad-to-return-inside-the-catch-which-is-good-practi – outis Apr 26 '10 at 15:34

10 Answers10

57

You can return normally from catch block. It's normally good functional code.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
Svisstack
  • 16,203
  • 6
  • 66
  • 100
23

One alternative would be to store the return value in a temporary variable:

public bool SomeFunction()
{
    bool success = true;
    try
    {
        //somecode
    }
    catch(Exception ex)
    {
        MessageBox.Show(ex.message);
        success = false;
    }

    return success;
}

But personally, I find the way you've written it (with one catch-all catch statement) to be more readable. On the other hand, if you are expecting a specific exception and you might have multiple paths to return success or not...

try
{
    DoTheImportantThing();
    DoTheOtherThingThatMightFailButWeDontCare();
}
catch (DontCareAboutItException ex)
{
    log.Info(ex);
}
catch (Exception ex)
{
    log.Error(ex);
    return false;
}

return true;

Then in my opinion you're best off pushing the return statements as close to the end as possible.

As a side note, depending on the application, consider logging the exceptions you catch rather than just showing them to the user. Logged exceptions are a lot more reliable than user's recounts of what happened.

Mark Rushakoff
  • 249,864
  • 45
  • 407
  • 398
16

If in the try block there's already a return statement I would probably put the other return at the end of the function:

try
{
    //somecode
    return true;
}
catch(Exception ex)
{
    MessageBox.Show(ex.message);
}
return false;

And this in order to avoid multiple returns if multiple exceptions need to be handled.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • 3
    If I follow the pattern of putting return inside catch, then compiler will remind me with error if in case somehow during refactoring I accidently delete my return statement inside the try. But if I keep return after the catch then the code will compile and it might end up in prod. – Unnie Nov 15 '17 at 18:07
12

It's ok, just keep in mind, that some code may executed after return instruction (return value will be cashed).

    try
    {
        return;
    }
    catch(Exception ex)
    {
        return;
    }
    finally
    {
        //some code
    }
mnistic
  • 10,866
  • 2
  • 19
  • 33
Andrew
  • 1,102
  • 1
  • 8
  • 17
8
public bool SomeFunction()
{
    try
    {
        //somecode
        return true;
    }
    catch(Exception ex)
    {
        MessageBox.Show(ex.message);
    }
    return false;
}

Personally I put the return statement at the bottom of the method instead of in the catch-block. But both are fine. It's all about readability (subjective) and guidelines in your organization.

Bart
  • 9,925
  • 7
  • 47
  • 64
3

Yes, it's perfectly normal.

Don't forget, that you can also use finally block to be executed after return.

Piotr Justyna
  • 4,888
  • 3
  • 25
  • 40
  • 4
    And therefore the code would be hard to read since code is executing after the return. – Romain Hippeau Apr 22 '10 at 11:56
  • 1
    Putting a return in a catch block might be hard to read because you expect the return to bypass the finally statement. The same could be said of putting a return block in the try block. Return usually means "all execution in the method stops and control passes back to the caller" while the finally block always runs when leaving the try/catch, so predicting which will take precedence it not easy. – Trisped Jan 12 '16 at 23:43
2

It isn't wrong, but if you used a resource, generally finally block is used to close it, instead of calling the close method twice, too. In that case, you may choose to use the return statement after the finally block.

Feyyaz
  • 3,147
  • 4
  • 35
  • 50
0

Makes perfect sense to me for a function which returns true on success and false on failure. I hope there is nothing wrong with it - I do it all the time :)

Ray
  • 21,485
  • 5
  • 48
  • 64
0

You can add a return in the catch block. You explicitly know that your code will return and continue execution instead of halting at the catch block.

try{
    //do something
}
catch{
    //error handling
    return;
}

Instead of having a lot of try-catch blocks in your code that can get confusing and just cause a mess in your code, it's better handle everything in your noe try catch and just check what the error returned was.

try{
    //do something
}
catch (Exception as err){
    if (err == "IOException"){
         //handle exception
    else if (err.indexOf("TypeError"){
         //handle exception
    }
}

These are two ways of checking what type the exception was so you can display a message accordingly. You can also just catch specific exceptions if you wanted so instead of Exception as err you can do catch IOException, ...

E. Oregel
  • 321
  • 2
  • 4
  • 15
-1

The primary purpose of a catch block is to provide a place where one can proceed an exceptional situation which occurred in a try block. So you caught an exception, proceeded it... and returned from a method. If the caller method does not care about the exception, this is absolutely normal.

n535
  • 4,983
  • 4
  • 23
  • 28