Code analisys ...

[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 ...

[Mark R. Dawson]

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.

"Jacek Jurkowski" wrote:

.... 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 ...

[Scott Coonce]

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
"Jacek Jurkowski" <pc*****@priv1.onet.pl> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

... 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 ...

[Jacek Jurkowski]

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!

[Derrick]

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
"Jacek Jurkowski" <pc*****@priv1.onet.pl> wrote in message
news:Or*************@tk2msftngp13.phx.gbl...

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!

[Ignacio Machin \( .NET/ C# MVP \)]

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,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Jacek Jurkowski" <pc*****@priv1.onet.pl> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

... 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 ...

[Kevin Spencer]

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.

"Jacek Jurkowski" <pc*****@priv1.onet.pl> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

... 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 ...

[Scott Coonce]

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

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:eP**************@tk2msftngp13.phx.gbl...

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.

"Jacek Jurkowski" <pc*****@priv1.onet.pl> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

... 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 ...

[Scott Roberts]

"Scott Coonce" <sd******@gmail.HEY_YOU.com> wrote in message
news:um**************@TK2MSFTNGP14.phx.gbl...

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.

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);
}
}

[Jon Skeet [C# MVP]]

Scott Roberts <sr*********@nospam.yahoo.com> wrote:

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.
As with any rule, there are always exceptions:

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

Very common, Very correct.

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);
}
}

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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Kevin Spencer]

> 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:

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.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

"Scott Coonce" <sd******@gmail.HEY_YOU.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... 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

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:eP**************@tk2msftngp13.phx.gbl...

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.

"Jacek Jurkowski" <pc*****@priv1.onet.pl> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

... 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 ...

[Scott Roberts]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Scott Roberts <sr*********@nospam.yahoo.com> wrote:

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

Very common, Very correct.

Hmm... I prefer:

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

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 :)
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.)

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)!

[Jacek Jurkowski]

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 :-)