public virtual IQueryable<Hubs> getribbons(bool includeChildObjects)
{
using (var dbHelper = new DbHelper())
{
DbDataReaderExtended reader = null;
try
{
const string sqlQuery = "Select * From [ribbons]";
reader = dbHelper.ExecuteReader(sqlQuery, CommandType.Text, true);
IList<Hubs> models = new List<Hubs>();
while (reader.Read())
{
var model = GetHubDataFromReader(reader);
if (includeChildObjects)
{
model.Satellites = GetAllSatellites(true,model.HubID).ToList();
}
models.Add(model);
}
return models.AsQueryable();
}
finally
{
if (reader != null) { reader.Close(); }
}
}
}
Here this functon is in Business logic Layer. Here i need to handle exceptions in catch block and log it there and after throw it to the function it has called first(Presentation Layer). and then in finally i need to close all the things.
Please show me how to do error handling Here.
i am very new to C# please give me some clarifications on this this will be very helpful for me.
Thanks in advance
Finally blocks will be called whether or not there is a throw.
Using statements will call IDisposable.Dispose() on anything that isn't null once the scope of the Using block is exited.
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.
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.
using statement provides similar functionality(clear resources) only for IDisposable objects.
While in case of finally block, it will get executed regardless of whether or not there is an exception, provided that a catch block must be there in the call stack to catch the exception. Finally block can be used by developers to clear the resources on their own, that has not consumed IDispoable interface.
Related
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
In other words, how are these two different?
try
{
// Something that can throw an error
}
catch
{
// Handle the error
}
finally
{
// Something that runs after the try statement
}
vs.
try
{
// Something that can throw an error
}
catch
{
// Handle the error
}
// Something that runs after the try statement
finally block always executes.
You can be sure, that this block will be executed no matter what.
Literally it is something like:
Try something, catch some exceptions(if told to and if they are there) and execute the
finally block finally.
If there is a break in the try block or an exception, it may cause the program to halt. In cases like these code that is mandarory to be executed, like closing open connections and returning items to the connection pools are writen in the finally block. The finally block ensures that the code written inside it will be executed.
If you only ever use general catches (i.e. catch without args or catch(Exception ex)), whether to put code in finally or after try/catch is basically a stylistic choice, as both a finally block and code after a try/catch will execute in any situation (barring deliberate escape mechanisms such as return).
However, if you use a narrow catch, and the exception isn't caught, what will happen is the finally block will still execute, however the code after the try/catch won't.
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.
I understand how try-catch works and how try-finally works, but I find myself using those (usually) in two completely different scenarios:
try-finally (or using in C# and VB) is mostly used around some medium-sized code block that uses some resource that needs to be disposed properly.
try-catch is mostly used either
around a single statement that can fail in a very specific way or
(as a catch-all) at a very high level of the application, usually directly below some user interface action.
In my experience, cases where a try-catch-finally would be appropriate, i.e., where the block in which I want to catch some particular exception is exactly the same block in which I use some disposable resource, are extremely rare. Yet, the language designers of C#, VB and Java seem to consider this to be a highly common scenario; the VB designers even think about adding catch to using.
Am I missing something? Or am I just overly pedantic with my restrictive use of try-catch?
EDIT: To clarify: My code usually looks like this (functions unrolled for clarity):
Try
do something
Aquire Resource (e.g. get DB connection)
Try
do something
Try
do something that can fail
Catch SomeException
handle expected error
do something else...
Finally
Close Resource (e.g. close DB connection)
do something
Catch all
handle unexpected errors
which just seems to make much more sense than putting any of the two catches on the same level as finally just to avoid indentation.
A quote from MSDN
A common usage of catch and finally
together is to obtain and use
resources in a try block, deal with
exceptional circumstances in a catch
block, and release the resources in
the finally block.
So to make it even more clear, think of the code that you want to run, in 99% of the cases it runs perfectly well but somewhere in the chunk there might occure an error, you don't know where and the resources created are expensive.
In order to be 100% sure that the resources are disposed of, you use the finally block, however, you want to pin-point that 1% of cases where the error occures, therefore you might want to set up logging in the catch-ing-section.
That's a very common scenario.
Edit - A Practical Example
There is some good examples here: SQL Transactions with SqlTransaction Class. This is just one of the many ways to use Try, Catch & Finally and it demonstrates it very well, even though a using(var x = new SqlTranscation) might be efficient some times.
So here goes.
var connection = new SqlConnection();
var command = new SqlCommand();
var transaction = connection.BeginTransaction();
command.Connection = connection;
command.Transaction = transaction;
Here comes the more interesting parts
///
/// Try to drop a database
///
try
{
connection.Open();
command.CommandText = "drop database Nothwind";
command.ExecuteNonQuery();
}
So let's imagine that the above fails for some reason and an exception is thrown
///
/// Due to insufficient priviligies we couldn't do it, an exception was thrown
///
catch(Exception ex)
{
transaction.Rollback();
}
The transaction will be rolled back! Remember, changes you made to objects inside the try/catch will not be rolled back, not even if you nest it inside a using!
///
/// Clean up the resources
///
finally
{
connection.Close();
transaction = null;
command = null;
connection = null;
}
Now the resources are cleaned up!
Not an answer to your question, but a fun fact.
The Microsoft implementation of the C# compiler actually cannot handle try-catch-finally. When we parse the code
try { Foo() }
catch(Exception e) { Bar(e); }
finally { Blah(); }
we actually pretend that the code was written
try
{
try { Foo(); }
catch(Exception e) { Bar(e); }
}
finally { Blah(); }
That way the rest of the compiler -- the semantic analyzer, the reachability checker, the code generator, and so on -- only ever has to deal with try-catch and try-finally, never try-catch-finally. A bit of a silly early transformation in my opinion, but it works.
Example:
Try
Get DB connection from pool
Insert value in table
do something else...
Catch
I have an error... e.g.: table already contained the row I was adding
or maybe I couldn't get the Connection at all???
Finally
if DB connection is not null, close it.
You can't really get a more "common" example. Pity that some people still forget to put the close connection in the Finally, where it belongs, instead of in the Try block... :(
I often write code that looks like this:
Handle h = ...
try {
// lots of statements that use handle
} catch (SomeException ex) {
// report exception, wrap it in another one, etc
} catch (SomeOtherException ex) {
// ...
} finally {
h.close();
}
So maybe you are just being overly pedantic ... e.g. by putting a try / catch around individual statements. (Sometimes it is necessary, but in my experience you don't usually need to be so fine-grained.)
There is nothing wrong with nesting try/catch/finally blocks. I actually use this quite often. I.e. when I use some resource that needs to be disposed or closed but I want only a single catch block around a larger code unit that needs to be aborted if some error occurs inside it.
try {
// some code
SomeResource res = new SomeResource();
try {
res.use();
} finally {
res.close();
}
// some more code
} catch( Exception ex ) {
handleError( ex );
}
This closes the resource as early as possible in either case (error or not) but still handles all possible errors from creating or using the resource in a single catch block.
I think you are quite right. From the .Net Framework Design Guidelines, written by some of the top architects at Microsoft:
DO NOT overcatch. Exceptions should
often be allowed to propagate up the
call stack.
In well-written code, try-finally [or
using] is far more common than
try-catch. It might seem
counterintuitive at first, but catch
blocks are not needed in a surprising
number of cases. On the other hand,
you should always consider whether
try-finally [or using] could be of use
for cleanup.
page 230 section 7.2
I would nearly always use try-catch-finaly in cases where you need to dispose something in all cases and you use the case to log the error and/or inform the user.
How about something like:
Dim mainException as Exception = Nothing
Try
... Start a transaction
... confirm the transaction
Catch Ex as Exception
mainException = Ex
Throw
Finally
Try
... Cleanup, rolling back the transaction if not confirmed
Catch Ex as Exception
Throw New RollbackFailureException(mainException, Ex)
End Try
End Try
Assuming here that the RollbackFailureException includes an "OriginalException" field as well as "InnerException", and accepts parameters for both. One doesn't want to hide the fact that an exception occurred during the rollback, but nor does one want to lose the original exception which caused the rollback (and might give some clue as to why the rollback happened).
Another use would be to dispose a file handle to an e-mail attachment when using the System.Web.Mail mail objects to send e-mail. I found this out when I had to programatically open a Crystal Report, save it to disk, attach it to an e-mail, and then delete it from disk. An explicit .Dispose() was required in the Finally to make sure I could delete it, especially in the event of a thrown exception.
In my experience, cases where a try-catch-finally would be appropriate, i.e., where the block in which I want to catch some particular exception is exactly the same block in which I use some disposable resource, are extremely rare. Yet, the language designers of C#, VB and Java seem to consider this to be a highly common scenario; the VB designers even think about adding catch to using.
you:
try {
//use resource
} catch (FirstException e) {
// dispose resource
// log first exception
} catch (SecondException e) {
// dispose resource
// log first exception
} catch (ThirdException e) {
// dispose resource
// log first exception
}
me:
try {
//use resource
} catch (FirstException e) {
// log first exception
} catch (SecondException e) {
// log first exception
} catch (ThirdException e) {
// log first exception
} finally {
// dispose resource
}
feel defference?)
Does the using catch the exception or throw it? i.e.
using (StreamReader rdr = File.OpenText("file.txt"))
{
//do stuff
}
If the streamreader throws an exception is it caught by using or thrown so the calling function can handle it?
When you see a using statement, think of this code:
StreadReader rdr = null;
try
{
rdr = File.OpenText("file.txt");
//do stuff
}
finally
{
if (rdr != null)
rdr.Dispose();
}
So the real answer is that it doesn't do anything with the exception thrown in the body of the using block. It doesn't handle it or rethrow it.
using statements do not eat exceptions.
All "Using" does is scope your object to the using block, and automatically calls Dispose() on the object when it leaves the block.
There is a gotcha though, if a thread is forcefully aborted by an outside source, it is possible that Dispose will never be called.
using allows the exception to boil through. It acts like a try/finally, where the finally disposes the used object. Thus, it is only appropriate/useful for objects that implement IDisposable.
It throws the exception, so either your containing method needs to handle it, or pass it up the stack.
try
{
using (
StreamReader rdr = File.OpenText("file.txt"))
{ //do stuff
}
}
catch (FileNotFoundException Ex)
{
// The file didn't exist
}
catch (AccessViolationException Ex)
{
// You don't have the permission to open this
}
catch (Exception Ex)
{
// Something happened!
}
Any exceptions that are thrown in the initialization expression of the using statement will propagate up the method scope and call stack as expected.
One thing to watch out for, though, is that if an exception occures in the initialization expression, then the Dispose() method will not be called on the expression variable. This is almost always the behavior that you would want, since you don't want to bother disposing an object that was not actually created. However, there could be an issue in complex circumstances. That is, if multiple initializations are buried inside the constructor and some succeed prior to the exception being thrown, then the Dispose call may not occur at that point. This is usually not a problem, though, since constructors are usually kept simple.
The using does not interfere with exception handling apart from cleaning up stuff in its scope.
It doesn't handle exceptions but lets exceptions pass through.
In your example, if File.OpenText throws, the Dispose will not be called.
If the exception happens in //do stuff, the Dispose will be called.
In both cases, the exception is normally propagated out of the scope, as it would be without the using statement.
If you don't specifically catch an exception it's thrown up the stack until something does
using guarantees* the object created will be disposed at the end of the block, even if an exception is thrown. The exception is not caught. However, you need to be careful about what you do if you try to catch it yourself. Since any code that catches the exception is outside the scope block defined by the using statement, your object won't be available to that code.
*barring the usual suspects like power failure, nuclear holocaust, etc
You can imagine using as a try...finally block without the catch block. In the finally block, IDisposable.Dispose is called, and since there is no catch block, any exceptions are thrown up the stack.
"using" does not catch exceptions, it just disposes of resources in the event of unhandled exceptions.
Perhaps the question is, would it dispose of resources allocated in the parentheses if an error also occured in the declaration? It's hard to imagine both happening, though.