Pointless Exception Handling?

[Cramer]

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?

[Jeff Winn]

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" <[e-mail] 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?

[Peter Morris]

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

[Jeroen Mostert]

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.

[Jon Skeet [C# MVP]]

On Jul 9, 8:35*am, "Peter Morris" <[e-mail]:

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

[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" <[e-mail]:

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