By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,422 Members | 1,414 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,422 IT Pros & Developers. It's quick & easy.

Pointless Exception Handling?

P: n/a
I just came across this code. The exception handling seems completely
pointless. Am I missing something?

try
{
con.Open();
da.Update(dsdata, "Products");
con.Close();
}
catch (SqlException)
{
throw;
}

Is there actually *any* good reason to catch an exception and then
immediately rethrow it without doing anything else?

Jul 9 '08 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Nope, that code is completely useless. If there was a transaction being done
with the update and the rollback was being done within the catch block I
could see it being of use then. As the code is written right now, I'd just
get rid of it.

"Cramer" <A@B.comwrote in message
news:e8**************@TK2MSFTNGP02.phx.gbl...
>I just came across this code. The exception handling seems completely
pointless. Am I missing something?

try
{
con.Open();
da.Update(dsdata, "Products");
con.Close();
}
catch (SqlException)
{
throw;
}

Is there actually *any* good reason to catch an exception and then
immediately rethrow it without doing anything else?

Jul 9 '08 #2

P: n/a
Is there actually *any* good reason to catch an exception and then
immediately rethrow it without doing anything else?
The only useful thing that may be ascertained from this is that you have a
developer that needs talking to :-)

Pete

Jul 9 '08 #3

P: n/a
Cramer wrote:
I just came across this code. The exception handling seems completely
pointless. Am I missing something?

try
{
con.Open();
da.Update(dsdata, "Products");
con.Close();
}
catch (SqlException)
{
throw;
}

Is there actually *any* good reason to catch an exception and then
immediately rethrow it without doing anything else?
I can think of only one: the developer could think of no other way to
quickly see if this particular code was throwing an exception, so they added
an empty handler to set a breakpoint in. It saves you having to decode a
call stack that may have been mangled by intermediate handlers, I suppose.

A better way of diagnosing such problems is to tell the debugger to break
whenever an exception is thrown (as opposed to when it's handled). This will
also allow you to track down when exceptions are being thrown needlessly
(even if they're handled afterwards).

--
J.
Jul 9 '08 #4

P: n/a
On Jul 9, 8:35*am, "Peter Morris" <mrpmorri...@SPAMgmail.comwrote:
Is there actually *any* good reason to catch an exception and then
immediately rethrow it without doing anything else?

The only useful thing that may be ascertained from this is that you have a
developer that needs talking to :-)
There is *one* temporary use for it - it makes it easy to add a
breakpoint for when the exception is thrown *just* at that location. I
wouldn't be surprised to learn that the code had been added during a
debugging session, and then the developer forgot to remove it.

Jon
Jul 9 '08 #5

P: n/a
JPK
Yes ! I do this all the time. NOte, if the code is in constant
development, and a "work in progress" then this is not a problem for me. If
the code is packages and sold to consumers then that is a different story.

JIM
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:ce**********************************@34g2000h sf.googlegroups.com...
On Jul 9, 8:35 am, "Peter Morris" <mrpmorri...@SPAMgmail.comwrote:
Is there actually *any* good reason to catch an exception and then
immediately rethrow it without doing anything else?

The only useful thing that may be ascertained from this is that you have a
developer that needs talking to :-)
There is *one* temporary use for it - it makes it easy to add a
breakpoint for when the exception is thrown *just* at that location. I
wouldn't be surprised to learn that the code had been added during a
debugging session, and then the developer forgot to remove it.

Jon

Jul 9 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.