Code analisys ...

  • Thread starter Thread starter Jacek Jurkowski
  • Start date Start date
J

Jacek Jurkowski

.... is warning me not to use catch(Exception e) as too general.
But how to determine what exception type should I use if
try section may cause a few exception types? How to determine
what kind of exceptions could such lines cause?
XmlTextReader xTr = new XmlTextReader(pFileName);

XmlSerializer xS = new XmlSerializer(typeof(T));

Catch(Exception) handles all of the possibilities and i don't
know how to choose more detailed exception type without
a risk of not catch one of them ...
 
Hi Jacek,
if you have access to a copy of Visual Studio 2005 then when you mouse
over a function in the code view it shows the exceptions it will throw inside
a tooltip, long with a description of the method. Otherwise to my knowledge
the only other way to know os to read the Micorosft documentation on each
method.

Mark.
 
As I have learned (from various members of this ng), catch only the
exceptions you want/are able to handle-- let everything else bubble up.

Scott
 
I saw the exceptions may cause a Send method on SMTP.
It's whole list! I will not catch every possible exception type
only because "Exception is to general" Looks like Code Analisys
gone mad!
 
I'm with Scott on this one.

The question is, what are you doing when you catch the exception? Are you
taking some additional action, or are you just telling the user that an
error occured? If it is the former, you must need to know what the specific
error condition was before you can retry - hence use multiple catch blocks
(for example, you would most likely handle a null argument exception
differently than a connection closed exception). If it is the latter, why
not just let it bubble up to your Main method, where you can catch all the
AppDomains unhandled exceptions.

Derrick
 
Hi,

If you know the kind of exception a method can throw AND you know how to
handle it you catch that especific exception.
You have to check the docs as there is no way to know what exception can
throw a method
If you do not know how to handle the exception just let it bubble up.


I do catch Exception in two cirscuntances though:
1- I do not know what exceptions the method can throw and I can treat all
exceptions in the same way.
2- I do not care about the precise error and all I care about is knowing if
there was an exception or not , most of the time this ends in a log entry
with the detailed info of the exception ( as well as any InnerException )
and maybe a "generic" user notification: "There was an error sending the
email blah blah" if appropiated.


cheers,
 
First of all, Code Analysis is not the Bible. A Code Analysis report is
designed to make you aware of situations that could potentially cause a
problem. It is not an error log of everything you need to fix. It is useful
for pointing out areas which may or may not need your attemtion. In other
words, it is a sort of rudimentary code review. However, while it may point
out what you need to review, it cannot tell you whether or not a change is
needed, as there are many ways to design and architect your app.

This is similar to the Warnings you see in your Error pane when you compile
your app in Visual Studio.Net. Not all warnings are problems that need to be
fixed. They are, however, things you need to review, make sure that there is
or is not a problem, and/or fix.

That said, try/catch is a useful tool, and can be used in a variety of ways.
In some designs, catching every Exception is a bad idea. In others, it is a
good idea. For example, I like for all of my apps to catch every exception
and log it. On the other hand, I don't want every exception to be ignored.
So, I have a HandleError utility that can either ignore or rethrow an
Exception, and the call to this function includes a boolean value to
indicate whether or not it should be thrown. It always logs it.

I also have a number of other Utility functions that parse different kinds
of Exceptions for the purpose of logging. They are all used by the
HandleError method, to log detailed information about the exception.

But, some exceptions need to be dealt with in different ways. Some, for
example, are recoverable, and some are not. This is where catching specific
types of exceptions comes in handy. The .Net SDK documents all of the
different Exception types that may be thrown by every method in the CLR.
When using such a method, it is important to study how each exception type
may be handled by your app, and do so if possible, for robustness.

As for bubbling up every exception that isn't identified, well, that depends
on the level you're working on. For business classes, this is generally a
good idea. In a user interface, it is not. A bubble can only rise as far as
the surface of the "water." The UI should be able to continue working when
most exceptions occur. So, you have to figure out at the UI level what to do
in each case when a business class method throws an exception, without
breaking the whole process.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.
 
Scott Coonce said:
As I have learned (from various members of this ng), catch only the
exceptions you want/are able to handle-- let everything else bubble up.
Click to expand...

As with any rule, there are always exceptions:

try
{
Save_some_changes();
Commit();
}
catch
{
Rollback();
throw;
}

Very common, Very correct.

Also,

foreach(MyItem item in BigListOfItems)
{
try
{
DoSomethingWith(item);
}
catch (Exception e)
{
LogExceptionSoTheWholeProcessDoesNotStop(e);
}
}
 
Just an idea, but in case the OP isn't quite clear on the catch syntax (and
i mean no disrespect here if you do):

try {
// something that'll throw an exception
}
catch(IOException ioex) {
// do something to clean up io
}
catch(ArgumentNullException) {
// code to handle ArgNullEx
}
....

My point being that the catch'es can be stacked...

Scott
 
Scott Roberts said:
As with any rule, there are always exceptions:

try
{
Save_some_changes();
Commit();
}
catch
{
Rollback();
throw;
}

Very common, Very correct.
Click to expand...

Hmm... I prefer:

try
{
SaveSomeChanges();
Commit();
committed = true;
}
finally
{
if (!committed)
{
Rollback();
}
}

Or, with the ADO.NET classes, just:

using (SqlWhatever ...)
{
SaveSomeChanges();
Commit();
}

as Dispose() then rolls back changes if they haven't been committed -
nice and simple :)
Also,

foreach(MyItem item in BigListOfItems)
{
try
{
DoSomethingWith(item);
}
catch (Exception e)
{
LogExceptionSoTheWholeProcessDoesNotStop(e);
}
}
Click to expand...

Indeed - top level controller blocks often need to catch anything so as
to keep going. (You may or may not want special handling of
ThreadAbortException though, depending on whether you think you know
better than whatever's trying to abort the thread.)
 
Jon Skeet said:
Hmm... I prefer:

try
{
SaveSomeChanges();
Commit();
committed = true;
}
finally
{
if (!committed)
{
Rollback();
}
}
Click to expand...

We'll just have to agree to disagree there! :-)
Or, with the ADO.NET classes, just:

using (SqlWhatever ...)
{
SaveSomeChanges();
Commit();
}

as Dispose() then rolls back changes if they haven't been committed -
nice and simple :)
Click to expand...

Ack! An implicit rollback? Agree to disagree again! :-)
Indeed - top level controller blocks often need to catch anything so as
to keep going. (You may or may not want special handling of
ThreadAbortException though, depending on whether you think you know
better than whatever's trying to abort the thread.)
Click to expand...

I guess you could say that you still want to catch specific exceptions (the
ones you specifically DON'T want to handle instead of the ones you
specifically DO want to handle)!
 
My point being that the catch'es can be stacked...
True, and a good idea sometimes. I sort of mentioned that, but it is buried
in my reply:

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.
 
I think i was going using the same guildenes You
wrote. I'v done it intuitive and I started to worry
about when CodeAnalisys caught my attention with
ist warnings. So there is nothing for me to change :-)

Thx. all of You :-)
 
Back
Top