Nested try/catch blocks
-
I'm somewhat hesitating about using nested try/catch blocks. The situation which makes me think about is the following situation. Some sample code to illustrate:
SqlConnection conn = new SqlConnection(connectionString);
conn.Open();
SqlTransaction trans = conn.BeginTransaction();try
{
string query = "query goes here";
SqlCommand command = new SqlCommand(query, conn, trans);
// add parameters
command.ExecuteNonQuery();
trans.Commit();
}
catch
{
trans.Rollback();
}
finally
{
if(conn != null)
{
conn.Close();
conn.Dispose();
}
}This block has 1 try/catch block but the problem resides in the "conn.Open();" line. When there is a network error the conn.Open() will throw an exception. Putting the conn.Open() in the try/catch block will invalidate the code which now resides in the catch/finally clauses. So I can use 2 sequential try/catch blocks or a nexted construction. What do you people think?
The consumer isn't a moron; she is your wife.
It won't invalidate anything. You can just put an (if conn != null) type block at the start of the second try/catch, and then your finally block will work fine. Indeed, command.ExecuteNonQuery would just force the catch and finally, if conn was null. I'm also not sure why conn couldn't be in the existing try block, just declare trans outside it, and begin it, inside.
Christian Graus Driven to the arms of OSX by Vista. "! i don't exactly like or do programming and it only gives me a headache." - spotted in VB forums. I can do things with my brain that I can't even google. I can flex the front part of my brain instantly anytime I want. It can be exhausting and it even causes me vision problems for some reason. - CaptainSeeSharp
-
It won't invalidate anything. You can just put an (if conn != null) type block at the start of the second try/catch, and then your finally block will work fine. Indeed, command.ExecuteNonQuery would just force the catch and finally, if conn was null. I'm also not sure why conn couldn't be in the existing try block, just declare trans outside it, and begin it, inside.
Christian Graus Driven to the arms of OSX by Vista. "! i don't exactly like or do programming and it only gives me a headache." - spotted in VB forums. I can do things with my brain that I can't even google. I can flex the front part of my brain instantly anytime I want. It can be exhausting and it even causes me vision problems for some reason. - CaptainSeeSharp
-
Ah yes, you're right. That would make it a viable solution indeed. *reminds himself not to start coding too early in the morning* ;)
The consumer isn't a moron; she is your wife.
Helfdane wrote:
reminds himself not to start coding too early in the morning
The best time is after :java: but before :beer:
Dave
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
Why are you using VB6? Do you hate yourself? (Christian Graus) -
Helfdane wrote:
reminds himself not to start coding too early in the morning
The best time is after :java: but before :beer:
Dave
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
Why are you using VB6? Do you hate yourself? (Christian Graus) -
I'm somewhat hesitating about using nested try/catch blocks. The situation which makes me think about is the following situation. Some sample code to illustrate:
SqlConnection conn = new SqlConnection(connectionString);
conn.Open();
SqlTransaction trans = conn.BeginTransaction();try
{
string query = "query goes here";
SqlCommand command = new SqlCommand(query, conn, trans);
// add parameters
command.ExecuteNonQuery();
trans.Commit();
}
catch
{
trans.Rollback();
}
finally
{
if(conn != null)
{
conn.Close();
conn.Dispose();
}
}This block has 1 try/catch block but the problem resides in the "conn.Open();" line. When there is a network error the conn.Open() will throw an exception. Putting the conn.Open() in the try/catch block will invalidate the code which now resides in the catch/finally clauses. So I can use 2 sequential try/catch blocks or a nexted construction. What do you people think?
The consumer isn't a moron; she is your wife.
Sequencial try/catches would be better. Something like:
SqlConnection conn;
SqlTransaction trans;try {
conn = new SqlConnection(connectionString);
conn.Open();
SqlTransaction trans = conn.BeginTransaction();
}
catch (SomeTypeOfException ex) {
// deal with exception
}
finally {
// transaction as well??if (conn != null) {
conn.Close();
conn.Dispose();
}
}// if we've got a trasnaction carry on:
if (trans != null) {
try {
string query = "query goes here";
SqlCommand command = new SqlCommand(query, conn, trans);
// add parameters
command.ExecuteNonQuery();
trans.Commit();
}
catch (SomeOtherException ex) {
// deal with exception
trans.Rollback();
}
finally {
if (conn != null) {
conn.Close();
conn.Dispose();
}
}
}
Panic, Chaos, Destruction. My work here is done.
-
Sequencial try/catches would be better. Something like:
SqlConnection conn;
SqlTransaction trans;try {
conn = new SqlConnection(connectionString);
conn.Open();
SqlTransaction trans = conn.BeginTransaction();
}
catch (SomeTypeOfException ex) {
// deal with exception
}
finally {
// transaction as well??if (conn != null) {
conn.Close();
conn.Dispose();
}
}// if we've got a trasnaction carry on:
if (trans != null) {
try {
string query = "query goes here";
SqlCommand command = new SqlCommand(query, conn, trans);
// add parameters
command.ExecuteNonQuery();
trans.Commit();
}
catch (SomeOtherException ex) {
// deal with exception
trans.Rollback();
}
finally {
if (conn != null) {
conn.Close();
conn.Dispose();
}
}
}
Panic, Chaos, Destruction. My work here is done.
-
Sequencial try/catches would be better. Something like:
SqlConnection conn;
SqlTransaction trans;try {
conn = new SqlConnection(connectionString);
conn.Open();
SqlTransaction trans = conn.BeginTransaction();
}
catch (SomeTypeOfException ex) {
// deal with exception
}
finally {
// transaction as well??if (conn != null) {
conn.Close();
conn.Dispose();
}
}// if we've got a trasnaction carry on:
if (trans != null) {
try {
string query = "query goes here";
SqlCommand command = new SqlCommand(query, conn, trans);
// add parameters
command.ExecuteNonQuery();
trans.Commit();
}
catch (SomeOtherException ex) {
// deal with exception
trans.Rollback();
}
finally {
if (conn != null) {
conn.Close();
conn.Dispose();
}
}
}
Panic, Chaos, Destruction. My work here is done.
doesn't the first
finallyblock close the connection resulting in exception when trying to execute a query in the second try block; and since the secondcatchblock also usesRollback, doesn't that throw another exception every time the function is called! :omg:regards :)
-
It won't invalidate anything. You can just put an (if conn != null) type block at the start of the second try/catch, and then your finally block will work fine. Indeed, command.ExecuteNonQuery would just force the catch and finally, if conn was null. I'm also not sure why conn couldn't be in the existing try block, just declare trans outside it, and begin it, inside.
Christian Graus Driven to the arms of OSX by Vista. "! i don't exactly like or do programming and it only gives me a headache." - spotted in VB forums. I can do things with my brain that I can't even google. I can flex the front part of my brain instantly anytime I want. It can be exhausting and it even causes me vision problems for some reason. - CaptainSeeSharp
Christian Graus wrote:
I can do things with my brain that I can't even google. I can flex the front part of my brain instantly anytime I want. It can be exhausting and it even causes me vision problems for some reason. - CaptainSeeSharp
:omg: Now I've seen everything! :laugh:
Cheers, Vikram.
Recent activities: TV series: Friends, season 8 Books: Freakonomics, by Steven Levitt and Stephen J Dubner.
Carpe Diem.
-
doesn't the first
finallyblock close the connection resulting in exception when trying to execute a query in the second try block; and since the secondcatchblock also usesRollback, doesn't that throw another exception every time the function is called! :omg:regards :)
:-O I didn't say it was perfect.
Panic, Chaos, Destruction. My work here is done.
-
For the situation above, Christian Graus gave a good hint on a potential solution, and so do you. But in general, why is sequential better than nested?
The consumer isn't a moron; she is your wife.
You put a try catch around the possible/probable points of failure and catch SPECIFIC errors. Catch and ignore is, generally, not a good idea. Ignoring a specific case can be okay so long as you impliment a valid recovery. ps. as pointed out the first finally is cr@p.
Panic, Chaos, Destruction. My work here is done.
-
I'm somewhat hesitating about using nested try/catch blocks. The situation which makes me think about is the following situation. Some sample code to illustrate:
SqlConnection conn = new SqlConnection(connectionString);
conn.Open();
SqlTransaction trans = conn.BeginTransaction();try
{
string query = "query goes here";
SqlCommand command = new SqlCommand(query, conn, trans);
// add parameters
command.ExecuteNonQuery();
trans.Commit();
}
catch
{
trans.Rollback();
}
finally
{
if(conn != null)
{
conn.Close();
conn.Dispose();
}
}This block has 1 try/catch block but the problem resides in the "conn.Open();" line. When there is a network error the conn.Open() will throw an exception. Putting the conn.Open() in the try/catch block will invalidate the code which now resides in the catch/finally clauses. So I can use 2 sequential try/catch blocks or a nexted construction. What do you people think?
The consumer isn't a moron; she is your wife.
Or both? :-D