Develop Reference

Should try/catch be inside or outside a using block?

The using block is shorthand for try/catch/finally I believe. In my code I have been putting a try/catch block inside the using block, so that I can catch and log exceptions using my own logger.
I have recently been wondering if the try should be on the outside, thus encapsulating the using block, or not.
To my mind I have previously been worried that if an exception is thrown then the using block will not Dispose() of my resource because it has jumped out of the block and into the catch handler. But I may be wrong.
Could somebody please clarify which is the correct way to use both using and try/catch together?
public HttpResponseMessage GetData(string x, int y)
{
using (var client = new HttpClient())
{
try
{
// do stuff
return response.Result;
}
catch (Exception ex)
{
// Something has gone badly wrong so we'll need to throw
// Log the info
throw;
}
}
}

using block is used to ensure the disposal (changed from ambiguous "immediate disposal" term to disposal as suggested by Mr. James) of the objects declared in the using statement as soon as the code is out of the using block. It is not exactly the shorthand for try/catch/finally. (Note that the compiler interprets it as try-finally however)
In your example
using (var client = new HttpClient())
{
} //client will be disposed at any time after this line
Depends on the case, you may consider of putting try-catch block inside or outside of using block.
For example, if you do not need to use the item in the using declaration multiple times (edit: what I mean by this is if you need the item both in the try and in the catch block - thanks for input by Mr. Cody Gray) - that is, you only need it in try, I would suggest to use using block inside of the try block.
Translated to your case, it depends on whether var client is intended to be used both for the try and the catch blocks. If it is, the using should be outside of the try-catch block. Else, it should be inside of the try block.
In general, as a rule of thumb, if the item is used both in the try and catch block, then declare using only once outside of the try-catch

It really depends on what resource it is you are worried about being disposed - if you are referring to client you should be fine. I'll explain why...
To my mind I have previously been worried that if an exception is thrown then the using block will not Dispose() of my resource because it has jumped out of the block and into the catch handler. But I may be wrong.
That's not how it works, the compiler will likely rewrite your code (probably more efficiently) like so:
try
{
try
{
// do stuff
return response.Result;
}
catch (Exception ex)
{
// Something has gone badly wrong so we'll need to throw
// Log the info
throw;
}
}
finally
{
if (client != null)
client.Dispose();
}
Under normal circumstances a finally block will always execute which means, even if you catch/rethrow an exception inside the using, your Dispose call will be triggered.
So from a technical point of view, inside vs outside doesn't really matter.

There is no "correct way" on it, only guidelines. However I myself try to localize every exception or any code as far as possible, meaning you should an exception where it can be thrown, but somewhere outside, at least as long as you do not have to let your exception bubble through different layers.

Either way will work. Using blocks are guaranteed to always call the Dispose() method on exit - this is true even for stack un-ravelling for exceptions being caught further down the stack.
Look at using Statement (C# Reference)
The using statement ensures that Dispose is called even if an exception occurs while you are calling methods on the object. You can achieve the same result by putting the object inside a try block and then calling Dispose in a finally block; in fact, this is how the using statement is translated by the compiler. The code example earlier expands to the following code at compile time (note the extra curly braces to create the limited scope for the object):

Personally, I would put the try/catch/finally inside the using block.
The reason for this is simply that the using block itself will not throw an exception, at least not from my experience. So for the sake of simplicity, I would deal with Exceptions where they occur.

As using compiles down to try/finally, just use try/catch/finally. "A finally block always executes, regardless of whether an exception is thrown."
var client = new HttpClient();
try
{
// do stuff
return response.Result;
}
catch (Exception ex)
{
// Something has gone badly wrong so we'll need to throw
// Log the info
throw;
}
finally
{
if (client != null)
client.Dispose();
}
The finally block could also be reduced to client?.Dispose(); with c# 6 and above.
All that said, HttpClient is a special case. Yes it is disposable but you should be careful about creating and disposing on the fly particularly in a long lived application, and may be better using a single shared instance.
https://www.aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/
https://medium.com/#nuno.caneco/c-httpclient-should-not-be-disposed-or-should-it-45d2a8f568bc

What is the purpose of "finally" in try/catch/finally

The syntax will change from language to language, but this is a general question.
What is the difference between this....
try
{
Console.WriteLine("Executing the try statement.");
throw new NullReferenceException();
}
catch (NullReferenceException e)
{
Console.WriteLine("{0} Caught exception #1.", e);
}
finally
{
Console.WriteLine("Executing finally block.");
}
and this....
try
{
Console.WriteLine("Executing the try statement.");
throw new NullReferenceException();
}
catch (NullReferenceException e)
{
Console.WriteLine("{0} Caught exception #1.", e);
}
Console.WriteLine("Executing finally block.");
I keep seeing it being used, so I assume there's a good reason to use finally, but I can't figure out how it's any different from just putting code after the statement since it will still run.
Is there ever a scenario where finally doesn't run?

In your example, it doesn't make a whole lot of difference.
Picture this, though:
try
{
Console.WriteLine("Executing the try statement.");
throw new NullReferenceException();
}
catch (SomeOtherException e)
{
Console.WriteLine("{0} Caught exception #1.", e);
}
finally
{
Console.WriteLine("Executing finally block.");
}
Console.WriteLine("Executing stuff after try/catch/finally.");
In this case, the catch won't catch the error, so anything after the whole try/catch/finally will never be reached. However, the finally block will still run.

try
{
throw new Exception("Error!");
}
catch (Exception ex)
{
throw new Exception(ex, "Rethrowing!");
}
finally
{
// Will still run even through the catch kicked us out of the procedure
}
Console.WriteLine("Doesn't execute anymore because catch threw exception");

It really depends - some other answers have very good reasons to use a Finally block. But I think the best reason is because you're doing exception handling. Things you do in a Finally block typically involve cleaning up resources to ensure proper continuation, regardless of whether or not an exception was thrown - to me that's still part of the exception handling, at least part of a "try something" operation.
IMHO the Finally scope highlights the fact that its code contains stuff that deserves special attention in case of an exception.

finally block is guaranted to be excuted.
So, in your example, results of both cases are looks same.
but if you use return or throw in your catch block, you can see what is difference.

Finally should be used to everything that needs to be done in order to keep a system consistent. This usually means release resources
Finally is always executed, no matter what exception was thrown. It should be used to release resources, in the following cases:
Finalize a connection
Close a file handler
Free memory
Close a database connection
Let me give a complete example. Imagine that that you are sending messages through the network. In pseudo-code:
// With finally | //Without finally
try{ | try{
send_message() | send_message()
} catch(NetworkError){ | } catch(NetworkError){
deal_with_exception() | deal_with_exception()
} finally { | }
finalizes_connection() | finalizes_connection()
} |
The only difference of both codes is when what is hold in the try block raises an exception that is not NetworkError, for example, MethodNotFound. In the first case, the method finalizes_connection() will be called, and in the second one, it will not.
A connection is naturally done through more than one program. So what happens in the case of a MethodNotFound exception to the other program? In the first case, your program will finish the connection and the other program and it will be happy. In the second case, the other program can be waiting for your response forever. What if the other program can only receive one connection per time? You just bugged the other program as well.
This would also apply for a file, for example, that you opened and other programs wouldn't be able to open for reading (in Windows). And for memory, it is never released and now you have a memory leak.

finally runs for both try and catch. It ensures that it will run, but it is not 100% guaranteed it will [some errors stop execution of code]

try block needs at least one catch or a finally.after executing all catch blocks the finally block will be executed.You can add any logic you need there which should be done ultimately.

Its a good practice to use finally to handle program crashes. finally will always run .If the function exits inside of the try catch block, or another error is thrown in either the try or the catch, the finally will still execute. You won't get that functionality not using the finally statement.

I don't know C#, but the purpose of a finally block in Java-ish languages is to ensure that system resources are relinquished, especially if garbage collection is irregular. It's the same principle for all. Consider the block
InputStream is = new FileInputStream("foo.txt");
OutputStream os = new FileOutputStream("D:/nonexistent/directory/bar.txt");
// Throws a FileNotFoundException.
The variable is is created successfully, and takes up system resources. Processes can only use a fixed number of file handles at a time. The variable os is never created, and an exception is thrown, and bubbles up to the caller. In the process, is goes out of scope, and becomes eligible for garbage collection.
However garbage collections are never guaranteed to happen, or they may happen at some indefinite time in the future. So, the system resources taken by is may never be freed. This can be costly, or can crash the program if it happens enough times. So, finally blocks were put into Java. Other languages have similar constructs. In C++, destructors are invoked deterministically. LISPy languages have unwind-protect, but those are usually packaged in with-foo macros.
In Java 6 and lower, one would do this:
try {
is = new FileInputStream("foo.txt");
os = new FileOutputStream("D:/nonexistent/directory/bar.txt");
// work...
} finally {
if (is != null) {
try {
is.close();
} catch (IOException ignored) {}
}
if (os != null) {
try {
os.close();
} catch (IOException ignored) {}
}
}
You can't just call is.close() because that might throw, and then os will never be closed. You have to check for null too. Sane people used Jakarta Commons-IO's IOUtils.closeQuietly() methods to replace the block:
} finally {
IOUtils.closeQuietly(is);
IOUtils.closeQuietly(os);
}
But Java 7 introduced a better solution: try-with-resources. C# 4 probably came first with something similar, Microsoft being quicker on the uptake than Snoracle.
try (
is = new FileInputStream("foo.txt"),
os = new FileOutputStream("D:/nonexistent/directory/bar.txt")
) {
// work...
}

finally always always runs. finally is like the catcher that never misses anything. In the example you mentioned, yes finally doesnt add any value. But finally is usually used to dispose/ release resources.

Use a 'try-finally' block without a 'catch' block

Are there situations where it is appropriate to use a try-finally block without a catch block?

You would use it to ensure some actions occur after the try content or on an exception, but when you don't wish to consume that exception.
Just to be clear, this doesn't hide exceptions. The finally block is run before the exception is propagated up the call stack.
You would also inadvertently use it when you use the using keyword, because this compiles into a try-finally (not an exact conversion, but for argument's sake it is close enough).
try
{
TrySomeCodeThatMightException();
}
finally
{
CleanupEvenOnFailure();
}
Code running in finally is not guaranteed to run, however the case where it isn't guaranteed is fairly edge - I can't even remember it. All I remember is, if you are in that case, chances are very good that not running the finally isn't your biggest problem :-) so basically don't sweat it.
Update from Tobias: finally will not run if the process is killed.
Update from Paddy: Conditions when finally does not execute in a .net try..finally block
The most prevalent example you may see is disposing of a database connection or external resource even if the code fails:
using (var conn = new SqlConnection("")) // Ignore the fact we likely use ORM ;-)
{
// Do stuff.
}
Compiles into something like:
SqlConnection conn;
try
{
conn = new SqlConnection("");
// Do stuff.
}
finally
{
if (conn != null)
conn.Dispose();
}

Good Explaination using code:
void MyMethod1()
{
try
{
MyMethod2();
MyMethod3();
}
catch(Exception e)
{
//do something with the exception
}
}
void MyMethod2()
{
try
{
//perform actions that need cleaning up
}
finally
{
//clean up
}
}
void MyMethod3()
{
//do something
}
If either MyMethod2 or MyMethod3 throws an exception, it will be caught by MyMethod1. However, the code in MyMethod2 needs to run clean up code, e.g. closing a database connection, before the exception is passed to MyMethod1.
http://forums.asp.net/t/1092267.aspx?Try+without+Catch+but+with+finally+doesn+t+throw+error+Why+no+syntax+error+

using is equivalent to try-finally. You will only use try-finally when you want to do some clean up inside finally and don't care about the exception.
The best approach will be
try
{
using(resource)
{
//Do something here
}
}catch(Exception)
{
//Handle Error
}
Doing so even clean up called by using fails, your code will not fail.
There are some condition when finally will not get executed.
If there is any StackOverflowException or ExecutingEngineException.
Process is killed from external source.

If you have, for example an unmanaged resource you create and use in the try block, you can use the finally block to ensure you release that resource. The finally block will always be executed despite what happens (e.g. exceptions) in the try block.
E.g. the lock(x) statement is really:
System.Threading.Monitor.Enter(x);
try { ... }
finally
{
System.Threading.Monitor.Exit(x);
}
The finally block will always get called to ensure the exclusive lock is released.

You need a finally block, when no matter which (if any) exceptions are caught or even if none are caught you still want to execute some code before the block exits. For instance, you might want to close an open file.
See Also try-finally

try/finally: when you do not want to handle any exceptions but want to ensure some action(s) occur whether or not an exception is thrown by called code.

I don't know anything about C#, but it seems that anything you could do with a try-finally, you could more elegantly do with a using statement. C++ doesn't even have a finally as a result of its RAII.

Here is a situation where you might want to use try finally: when you would normally use a using statement, but can't because you are calling a method by reflection.
This won't work
using (objMsg = Activator.CreateInstance(TypeAssist.GetTypeFromTypeName("omApp.MessagingBO")))
{
}
instead use
object objMsg = null;
try
{
objMsg
= Activator.CreateInstance(TypeAssist.GetTypeFromTypeName("myAssembly.objBO"));
strResponse = (string)objMsg.GetType().InvokeMember("MyMethod", BindingFlags.Public
| BindingFlags.Instance | BindingFlags.InvokeMethod, null, objMsg,
new object[] { vxmlRequest.OuterXml });
}
finally
{
if (objMsg!=null)
((IDisposable)objMsg).Dispose();
}

Have a look at the following link:
https://softwareengineering.stackexchange.com/questions/131397/why-use-try-finally-without-a-catch-clause
It depends on the architecture of your application and the operation you are performing in the block.

1.we can use the try block without catch but we should use the catch/finally,
any one of them.
2.We can't use only try block.

C#: why bother having a 'finally' clause? [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Why use finally in C#?
In C#, what is the point of having a finally clause?
eg.
try {
// do something
}
catch (Exception exc)
{
// do something
}
// do something
Won't the code at the end execute anyway? What is the point of a finally block?

Finally is for the event that even the catch throws an exception, plus it allows you to exewcute code on success and failure, the finally will ALWAYS be executed. ALWAYS.
Ok, except when the application is killed at the system level or the computer explodes.

The finally ensures that anything in the block will be executed, regardless if the previous two statements are activated.
A good example would be to release database resources.
Try-Catch-Finally
Example:
try
{
//Open a database connection
}
catch
{
//Catch exception, database connection failed
}
finally
{
//Release the opened database connection resources
}

There are pieces of your code that you want to execute regardless of the success of previous code. By using Try/Catch/Finally you are able to benefit from the error handling.

Because there are certain objects that you should perform cleanup on, otherwise it will cause issues for your application.
The constantly used example is using a SqlConnection:
SqlConnection conn = new SqlConnection(connString);
try
{
conn.Open();
throw new ArgumentException();
}
catch(SqlException ex)
{
}
In this case, the SqlConnection is left open with no way of closing it because you handle a SqlException, but ArgumentException is thrown. If you used a finally block, this wouldn't happen because the finally block code would execute:
try
{
conn.Open();
throw new ArgumentException();
}
catch(SqlException ex)
{
}
finally
{
conn.Dispose();
}

The finally block is garaunteed to run when an exception is caught, even if the exception handling block throws more exceptions. Often used for cleaning up certain kinds of resources such as open file handles, network connections, etc...
Good examples here:
http://dotnetperls.com/finally
http://www.csharp-station.com/Tutorials/lesson15.aspx

The Finally ensures that whatever is in it will fire if the try works or fails. In a scenario where a catch occurs you are not guaranteed that everything at the last //do something will occur.

The code in the Finally block always executes, regardless of if an exception was thrown or not. The code following the exception block may or may not execute if the path returns in the catch.

throw exception in the try block rather than catch block?

I've inherited code in our project which looks like this. It's a method in a class.
protected override bool Load()
{
DataAccess.SomeEntity record;
try
{
record = _repository.Get(t => t.ID.Equals(ID));
if (record == null)
{
throw new InvalidOperationException("failed to initialize the object.");
}
else
{
this.ID = record.ID;
// this.OtherProperty = record.SomeProperty;
// etc
}
}
catch (Exception)
{
throw;
}
return true;
}
If I then call this Load method from my UI layer, I'd probably want to have a try catch block to catch any exception caused by the failure to Load the instance, e.g. InvalidOperationException, but the above code feels wrong to me.
Won't the InvalidOperationException be swallowed by the catch statement? that catch statement will also catch potential problems with _repository.Get, as well as potential problems with the setting of properties if the record is valid.
I thought I should perhaps restructure it by adding more try catch statements to handle the Get operation and property setting operations separately, or add more catch blocks handling different exceptions, but I asked a colleague, and he suggested that the try catch is irrelevant in this case, and should be removed completely, leaving it like:
protected override bool Load()
{
DataAccess.SomeEntity record;
record = _repository.Get(t => t.ID.Equals(ID));
if (record == null)
{
throw new InvalidOperationException("failed to initialize the object.");
}
else
{
this.ID = record.ID;
// this.OtherProperty = record.SomeProperty;
// etc
}
return true;
}
I'd like some second opinions, I've only just started taking an interest in exception handling, so I'd like to make sure I am doing it the right way according to best practices.

When you do this:
catch (Exception)
{
throw;
}
You are essentially not handling the exception. That does not however mean you are ignoring it. The throw statement will propagate the exception up the stack. For the sake of clean readable code your final example is much better.

If you're catching exceptions in the calling method ( Ithink) you should only catch exceptions which you expect. If the exception is a problem for Load(), then throw a new exception to the calling method, with better information about the exception.

Excellent! You are definitely on the right track. The previous implementation doing nothing other than re-throwing exceptions which is unnecessary. You should only handle specific exceptions that you are anticipating in the business layer, otherwise let them naturally go up the call stack up to the UI layer.
As best practice, only re-throw exceptions when you want to add some additional debug information, in which case you will need to define a custom exception

The exception will be caught by the catch statement but since it has a throw statement, it'll throw the exception back out. This has the same effect as if you didn't have a try/catch at all, so your colleague is right in suggesting leaving it out.
There isn't much of a point to adding exception-handling code if you don't actually handle the exception in any way.

I agree with your colleague, you should only catch exceptions that you know need to be caught. I typically leave out any try catch blocks unless I know exactly why I need it in a particular situation. This is because you tend to hide the real bugs in your code if you just put try catch block around everything. Leave the error handling off until you absolutely need it - start off with a single global error handler at the highest point in the application - if this is asp.net you can hook the application error event and log errors there, but my point is don't add try catch blocks unless you know why your adding them and write code that handles error cases not traps them.
Enjoy!