views:

461

answers:

10

Is is 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;
    }

}
+13  A: 

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

Svisstack
+5  A: 

it is fine, why not?

Andrey
A: 

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
+8  A: 

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
+2  A: 
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
A: 

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  A: 

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

    try
    {
        return;
    }
    catch(Exception ex)
    {
        return;
    }
    finally
    {
        //some code
    }
Andrew
+2  A: 

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
A: 

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.

sahs
`finally` would still execute even with a return in the try block.
fearofawhackplanet
In this case return statement after finally block will just cause confusion. It will work, but it is a good practice not to complicate your code (too much).
Piotr Justyna
A: 

Yes, it's perfectly normal.

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

Piotr Justyna
And therefore the code would be hard to read since code is executing after the return.
Romain Hippeau
I don't get it, do you consider finally block hard to read?
Piotr Justyna