This code is part of an application that reads from and writes to an ODBC connected database. It creates a record in the database and then checks if a record has been succes
the finally block would be executed, then would execute the return false; at the bottom.
Wrong. finally
doesn't swallow the exception. It honors it and the exception will be thrown as normal. It will only execute the code in the finally before the block ends (with or without an exception).
If you want the exception to be swallowed, you should use a catch
block with no throw
in it.
The warning is because you didn't use catch
and your method is basically written like this:
bool SomeMethod()
{
return true;
return false; // CS0162 Unreachable code detected
}
Since you use finally
solely to dispose, the preferred solution is to utilize using
pattern:
using(var command = new WhateverCommand())
{
...
}
That's enough, to ensure what Dispose
will be called. It's guaranteed to be called either after successful execution of code block or upon (before) some catch
down in call stack (parent calls are down, right?).
If it wouldn't be about disposing, then
try { ...; return true; } // only one return
finally { ... }
is enough, since you will never have to return false
at the end of method (there is no need for that line). Your method is either return result of command execution (true
or false
) or will throw an exception otherwise.
Consider also to throw own exceptions by wrapping expected exceptions (check out InvalidOperationException constructor):
try { ... }
catch(SomeExpectedException e)
{
throw new SomeBetterExceptionWithExplanaition("...", e);
}
This is typically used to say something more meaningful (useful) to the caller than nested call exception would be telling.
Most of times you don't really care about unhandled exceptions. Sometimes you need to ensure that finally
is called even if exception is unhandled. In this case you simply catch it yourself and re-throw (see this answer):
try { ... }
catch { ...; throw; } // re-throw
finally { ... }
Compiler Warning (level 2) CS0162
Unreachable code detected
The compiler detected code that will never be executed.
Which is just saying, the Compiler understands enough through Static Analysis that it can't be reached and completely omits it from the compiled IL (hence your warning).
Note : You can prove this fact to your self by trying to Step on to the Unreachable Code with the debugger, or using an IL Explorer.
The finally
may run on an Exception, (though that aside) it doesn't change the fact (in this case) it will still be an Uncaught Exception. Ergo, the last return
will never get hit regardless.
If you want the code to continue onto the last return
, your only option is to Catch the Exception;
If you don't, just leave it the way it is and remove the return
.
Example
try
{
command.CommandText = sb.ToString();
returnValue = command.ExecuteNonQuery();
return returnValue == 1;
}
catch(<some exception>)
{
// do something
}
finally
{
command.Dispose();
}
return false;
To quote the documentation
try-finally (C# Reference)
By using a finally block, you can clean up any resources that are allocated in a try block, and you can run code even if an exception occurs in the try block. Typically, the statements of a finally block run when control leaves a try statement. The transfer of control can occur as a result of normal execution, of execution of a break, continue, goto, or return statement, or of propagation of an exception out of the try statement.
Within a handled exception, the associated finally block is guaranteed to be run. However, if the exception is unhandled, execution of the finally block is dependent on how the exception unwind operation is triggered. That, in turn, is dependent on how your computer is set up.
Usually, when an unhandled exception ends an application, whether or not the finally block is run is not important. However, if you have statements in a finally block that must be run even in that situation, one solution is to add a catch block to the try-finally statement. Alternatively, you can catch the exception that might be thrown in the try block of a try-finally statement higher up the call stack. That is, you can catch the exception in the method that calls the method that contains the try-finally statement, or in the method that calls that method, or in any method in the call stack. If the exception is not caught, execution of the finally block depends on whether the operating system chooses to trigger an exception unwind operation.
Lastly
When using anything that supports the IDisposable
interface (which is designed to release unmanaged resources), you can wrap it in a using statement. The compiler will generate a try {} finally {}
and internally call Dispose()
on the object.
The last statement return false
is unreachable, because the try block is missing a catch
part that would handle the exception, so the exception is rethrown after the finally
block and the execution never reaches the last statement.
You have two return paths in your code, the second of which is unreachable because of the first. The last statement in your try
block return returnValue == 1;
provides your normal return, so you can never reach the return false;
at the end of the method block.
FWIW, order of exection related to the finally
block is: the expression supplying the return value in the try block will be evaluated first, then the finally block will be executed, and then the calculated expression value will be returned (inside the try block).
Regarding flow on exception... without a catch
, the finally
will be executed upon exception before the exception is then rethrown out of the method; there is no "return" path.
On your code:
private static bool createRecord(String table, IDictionary<String,String> data, System.Data.IDbConnection conn, OdbcTransaction trans) {
[... some other code ...]
int returnValue = 0;
try {
command.CommandText = sb.ToString();
returnValue = command.ExecuteNonQuery();
return returnValue == 1; // You return here in case no exception is thrown
} finally {
command.Dispose(); //You don't have a catch so the exception is passed on if thrown
}
return false; // This is never executed because there was either one of the above two exit points of the method reached.
}
the finally block would be executed, then would execute the return false; at the bottom
This is the flaw in your logic because the finally
block won't catch the exception and it will never reach the last return statement.