Your opinion about rethrowing exceptions

[Guest]

In my opinion rethrowing exceptions without providing anny extra information
is a totall waste

Examples :

in my opinion wrong :
A:
Public sub DoSomeStuff()
Try
do it
Catch ex As Exception
Throw New Exception(ex.tostring )
End Try
End sub


in my opinion plausible
B:
Public sub DoSomeStuff()
Try
do it
Catch ex As Exception
Throw New Exception("extra info about this exception ",ex)
End Try
End sub

In my opinion most common if this method is in a parent exception handler
C:
Public sub DoSomeStuff()
do it
End sub

please note that the three versions are beeing called in a parent exception
handler
However some people here seem to stick with version A

I told them this is a waste of resources , they on the other hand tell me i
am wrong , as the exception would not be bubled up , if you do not rethrow (
ofcourse i tested this and on my comp it does )

I would like to hear your throughts about the subject

Regards

Michel

 

[Patrice]

They perhaps changed something in their IDE (I believe there is a "stop on
unhandled exception" checkbox). Do they have the same behavior when running
outise of the IDE ?

It can still be usefull if you want to dispose resources (this is what
"using" does) but there is a difference between throwing a new exception and
throwing the same exception (omitting the catch clause will do the job).

Of course if you do nothing at all, there is no point in catching the
exception in the first place (it should be catched by the application global
exception handler).


"Michel Posseth [MCP]" <[email protected]> a écrit
dans le message de (e-mail address removed)...

 

[Oenone]

In my opinion rethrowing exceptions without providing anny extra
information is a totall waste

Agreed. Catching an exception just to rethrow it again it usually fairly
pointless. Perhaps you might want to put a breakpoint on the Throw line so
that you can intercept that particular exception rather than using the break
on unhandled exceptions option, but even then that's just a debugging
feature and not something to adopt as a project-wide standard.

I also wanted to point out a problem in the code you posted however... Both
your examples A and B actually throw new exceptions, rather than rethrowing
the exception that they caught. In the case of example B this has the
advantage of being able to add extra information, but the effect of this is
that you lost the call stack that has so far been added to the exception
when the new one is thrown. If you did want to catch and rethrow the
exception, you should just use the "Throw" statement without any parameters
at all:

\\\
Public sub DoSomeStuff()
Try
do it
Catch ex As Exception
Throw
End Try
End sub
///

The effects of the exception handling in the above example are exactly the
same as not using a Try/Catch block at all.

I wouldn't be surprised if the compiler optimises this out for Release
builds, but I haven't tested that to be sure.

 

[Guest]

Well ...

It seems like you both agree with me

As you probably understood this was coming from a discussion with my
colleguess who are catching and throwing exceptions without providing extra
information as in example A:

They told me i was doing it wrong , ( cause i did not catch the error at all
in the io routine but in the parent call ) .

I told them they wasted resources without anny functional use

Thanks for shining your light on the subject to you both


regards

Michel

 

[Brian Gideon]

Well ...

It seems like you both agree with me

As you probably understood this was coming from a discussion with my
colleguess who are catching and throwing exceptions without providing extra
information as in example A:

They told me i was doing it wrong , ( cause i did not catch the error at all
in the io routine but in the parent call ) .

I told them they wasted resources without anny functional use

Thanks for shining your light on the subject to you both

regards

Michel

Michel,

I agree as well. In fact, doing it their way you lose two important
pieces of information: 1) The stack trace and 2) the exception type
and it's state. It's barely one step above just swallowing the
exception. Ask your peers what benefit they see by doing it their
way.

Brian

 

[Michel Posseth [MCP]]

Hello Brian

Wel on first notice ( when they saw that i did not use this construct ) they
told me that this needed to be done to get the error message reflected in
the calling assembly ( as these methods are in seprate dll`s ) However
when i told them about the exception mechanism ( exceptions are bubled up
untill it reaches a handler in the calling chain ) They told me i needed
to implent it because they also did ,, but without a good explanation so
i just implemented it with a comment in source that i now that it is foolish
.

However after this event i wanted to be sure that i am not the one missing
something here

I dare to say that i am pretty experienced , but i am still a person who is
going to hunt for information before he stands ground ( i could have been
wrong and learned something new today ,,, but until sofar i only meet my
equals or persons that i can learn something from in this group :- ) )

regards

Michel

 

[RobinS]

I have done this in one case, although I think it's probably going to be
temporary.

I have a 3-layer Windows Forms app. I have a class that is BindingList(Of
People) that I am showing in a DataGridView. The user can add, change, and
delete records from the list. When he hits save, I then process all of his
changes.

If I have an error when trying to process the data, I throw it back up to
the UI. That way, the user knows there was an error.

I think in the long-term, I'd have it capture the errors and put them in a
list and continue processing, then present a list to the user so he would
know which records did not process successfully. That's my theory, anyway.

Opinions welcome.

Robin S.

 

[aaron.kempf]

yeah I reccomend you just use Access Data Projects
then you get errors; you deal with them the old fashioned way; you
write them to a database table.

the ADP client works on every operating system; unlike this VB 2005
_CRAPWARE_

the whole .NET strategy still isn't baked yet.
they think that they can sell us on .NET 3.0 and 2.0 and 1.0 and 1.1
won't run on Vista?

Why does VB6 have better upgrade support than VB 2005?

-Aaron

 

[Bruce W. Darby]

I think in the long-term, I'd have it capture the errors and put them in a
list and continue processing, then present a list to the user so he would
know which records did not process successfully. That's my theory, anyway.

Opinions welcome.

Robin S.

I think you would really have to take a look at the audience that will be
using the software, Robin. The 'big' man in the company had India create us
a new knowledgebase app and I'm happily transferring our old knowledgebase
over to it. In doing so, I have to actually construct the format of the new
knowledgebase, as the customer will be seeing some of this as well as the
techs. I was moving right along, thinking all was going well and then I
attempted to save one article that I'd spent almost 45 minutes on. When I
saved, I was taken to the login screen because the app had timed out while I
was feverishly typing away. No warning, no errors, but I lost all that work
and had to recreate it. I'm thinking the better way would be a combination
of the two methods you describe. An error message that appears on the first
error asking if the user would like to stop and fix things before
continuing. If yes, exit the routine and allow the user to make any changes.
If no, finish the processing of data and log any further errors without
stopping.

Bruce

 

[Stephany Young]

Interesting discussion!

In my view, every .NET application should have a 'global' exception handler.
There is nothing worse than having an application 'crash' because of an
unhandled exception. And ... it would be a very brave developer who would
claim to have 'handled' every exception that could possibly occur in a given
application.

Even given the most rigorous of testing, once the application gets into the
hands of users, (<grin>the bane of a developers life</grin>), they are sure
to encounter exceptions that you havn't anticipated because they tend to
attempt to do things with the application that you haven't anticipated.

Having a 'global' exception handler allows us to take advantage of code
like:

Try
' some operation here
Catch _ex As ArgumentException
' handle an expected ArgumentException
Catch _ex As IOException
' handle an expected IOException
Catch
' We don't expect any other exceptions,
' but if we get one then throw it up the line
Throw
Finally
' some clean-up stuff here
End Try

Instead of having to try and handle exceptions that we don't expect to
happen, the Throw in the third catch 'throws' the exception (with the stack
trace intact) up the line to the next enabled handler. If there are no
others, it will be caught by the 'global' exception handler.

Exceptions caught by the 'global' exception handler can then be diagnosed
and, for instance a further catch added to th the above in a maintenance
release.

 

[RobinS]

I think you would really have to take a look at the audience that will be
using the software, Robin. The 'big' man in the company had India create
us a new knowledgebase app and I'm happily transferring our old
knowledgebase over to it. In doing so, I have to actually construct the
format of the new knowledgebase, as the customer will be seeing some of
this as well as the techs. I was moving right along, thinking all was
going well and then I attempted to save one article that I'd spent almost
45 minutes on. When I saved, I was taken to the login screen because the
app had timed out while I was feverishly typing away. No warning, no
errors, but I lost all that work and had to recreate it. I'm thinking the
better way would be a combination of the two methods you describe. An
error message that appears on the first error asking if the user would
like to stop and fix things before continuing. If yes, exit the routine
and allow the user to make any changes. If no, finish the processing of
data and log any further errors without stopping.

Bruce

Actually, I would have already checked for user errors before starting the
update process. What I'm concerned about is if it can't write a record
because of some duplication that has slipped in there since I last checked,
or because there's a problem accessing the database, or something like that
that the user has little or no control over.

What I actually would like to do is remove the rows from the grid as they
are updated, leaving only rows that have errors behind, so the user can see
which ones have errors. Ideally, I would implement the ErrorProvider and
show the errors that occurred to the user. Or pop up another screen showing
which rows they went with, although I think the ErrorProvider idea is a
better one, because I can implement that in the grid already displaying the
records.

Robin S.

 

[Oenone]

Hi Stephany,

I agree with everything you said in your message, but just want to point out
once again that:

\\\
Try
' some operation here
Catch _ex As ArgumentException
' handle an expected ArgumentException
Catch _ex As IOException
' handle an expected IOException
Catch
' We don't expect any other exceptions,
' but if we get one then throw it up the line
Throw
Finally
' some clean-up stuff here
End Try
///


....the final Catch in that code (that simply re-Throws the exception) is
still unnecesary -- which I believe is the basis of Michel's original
question. The following code is functionally identical:

\\\
Try
' some operation here
Catch _ex As ArgumentException
' handle an expected ArgumentException
Catch _ex As IOException
' handle an expected IOException
Finally
' some clean-up stuff here
End Try
///

Any exception that is not caught by the two handlers specified (for
ArgumentException and IOException) automatically gets thrown up to the next
exception handler, bubbling up until the global exception handler (assuming
there is one) finally catches it. All of the stack trace will be intact,
including all of the functions that didn't explicitly catch and re-throw the
exception (such as my modified version of the code above).

 

[Stephany Young]

Yes, absolutely!

However, I got carried away and over-simplified my example.

There is a case for explicitly throwg an exception up the line, if one
wanted to do 'some' partial handling first:

Try
' some operation here
Catch _ex As ArgumentException
' handle an expected ArgumentException
Catch _ex As IOException
' handle an expected IOException
Catch _ex As Exception
' We don't expect any other exceptions,
' but if we get one then throw it up the line
' after doing some partial handling first

' some partial handling code goes here
Throw _ex

Finally
' some clean-up stuff here
End Try

I recognise that it would be rare that one would need to do this but I have
come across it and in that context it's use was perfectly valid and logical.
Note that to achieve it one needs to use:

Catch _ex As Exception

' some partial handling code goes here
Throw _ex

rather than:

Catch
' some partial handling code goes here
Throw

 

[Cor Ligthert \(MVP\)]

Robin,

This is standard.

What I actually would like to do is remove the rows from the grid as they
are updated, leaving only rows that have errors behind, so the user can
see which ones have errors. Ideally, I would implement the ErrorProvider
and show the errors that occurred to the user. Or pop up another screen
showing which rows they went with, although I think the ErrorProvider idea
is a better one, because I can implement that in the grid already
displaying the records.

I am not sure of you know this because what you write above.

Set the dataadapter property ContinueUpdateOnError to true.

The effect will be that the rowerror property in the datarows will be
filled.

That will be showed in the datagrid automaticly in the way as a
errorprovider

Cor

 

[Brian Gideon]

Interesting discussion!

In my view, every .NET application should have a 'global' exception handler.
There is nothing worse than having an application 'crash' because of an
unhandled exception. And ... it would be a very brave developer who would
claim to have 'handled' every exception that could possibly occur in a given
application.

[snip]

Exceptions caught by the 'global' exception handler can then be diagnosed
and, for instance a further catch added to th the above in a maintenance
release.

Hi,

I don't know. One advantage of allowing unexpected exceptions to
propagate unhandled is that the CLR will eventually catch it, report
it, and then terminate the application making it obvious to the end
user that something went wrong. Also, sometimes terminating the
appliction is the only way to recover from an error. If you catch all
exceptions then a bug may go unreported for a long time. I guess it
really depends on what you do with the exception though.

Brian

 

[RobinS]

I'm not using a data adapter. The rows in my DataGridView are a class that
is a BindingList(Of Company), i.e. a list of business objects. I'm handling
the updates myself. In retrospect, I think I would *not* remove the rows
that succeeded, I would just mark the rows that had problems, using the
ErrorProvider.

Good idea, though; I'll keep it for future reference.

Robin S.
-------------------------