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(p FileName);

XmlSerializer xS = new XmlSerializer(t ypeof(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]

RE: Code analisys ...

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:
[color=blue]
> .... 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(p FileName);
>
> XmlSerializer xS = new XmlSerializer(t ypeof(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 ...
>
>
>[/color]

[Scott Coonce]

Re: Code analisys ...

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" <pcmigel@priv1. onet.pl> wrote in message
news:%23S57$wW1 FHA.4032@TK2MSF TNGP15.phx.gbl. ..[color=blue]
> ... 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(p FileName);
>
> XmlSerializer xS = new XmlSerializer(t ypeof(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 ...
>[/color]

[Jacek Jurkowski]

Re: Code analisys ...

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]

Re: Code analisys ...

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" <pcmigel@priv1. onet.pl> wrote in message
news:Or2Y8KX1FH A.664@tk2msftng p13.phx.gbl...[color=blue]
>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!
>[/color]

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

Re: Code analisys ...

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" <pcmigel@priv1. onet.pl> wrote in message
news:%23S57$wW1 FHA.4032@TK2MSF TNGP15.phx.gbl. ..[color=blue]
> ... 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(p FileName);
>
> XmlSerializer xS = new XmlSerializer(t ypeof(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 ...
>[/color]

[Kevin Spencer]

Re: Code analisys ...

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" <pcmigel@priv1. onet.pl> wrote in message
news:%23S57$wW1 FHA.4032@TK2MSF TNGP15.phx.gbl. ..[color=blue]
> ... 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(p FileName);
>
> XmlSerializer xS = new XmlSerializer(t ypeof(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 ...
>[/color]

[Scott Coonce]

Re: Code analisys ...

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(IOExcepti on ioex) {
// do something to clean up io
}
catch(ArgumentN ullException) {
// code to handle ArgNullEx
}
....

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

Scott



"Kevin Spencer" <kevin@DIESPAMM ERSDIEtakempis. com> wrote in message
news:ePXWS7Y1FH A.2792@tk2msftn gp13.phx.gbl...[color=blue]
> 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" <pcmigel@priv1. onet.pl> wrote in message
> news:%23S57$wW1 FHA.4032@TK2MSF TNGP15.phx.gbl. ..[color=green]
>> ... 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(p FileName);
>>
>> XmlSerializer xS = new XmlSerializer(t ypeof(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 ...
>>[/color]
>
>[/color]

[Scott Roberts]

Re: Code analisys ...


"Scott Coonce" <sdcoonce@gmail .HEY_YOU.com> wrote in message
news:umEIGEX1FH A.1108@TK2MSFTN GP14.phx.gbl...[color=blue]
> 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.[/color]

As with any rule, there are always exceptions:

try
{
Save_some_chang es();
Commit();
}
catch
{
Rollback();
throw;
}

Very common, Very correct.

Also,

foreach(MyItem item in BigListOfItems)
{
try
{
DoSomethingWith (item);
}
catch (Exception e)
{
LogExceptionSoT heWholeProcessD oesNotStop(e);
}
}

[Jon Skeet [C# MVP]]

Re: Code analisys ...

Scott Roberts <sroberts999@no spam.yahoo.com> wrote:[color=blue][color=green]
> > 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.[/color]
>
> As with any rule, there are always exceptions:
>
> try
> {
> Save_some_chang es();
> Commit();
> }
> catch
> {
> Rollback();
> throw;
> }
>
> Very common, Very correct.[/color]

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 :)
[color=blue]
> Also,
>
> foreach(MyItem item in BigListOfItems)
> {
> try
> {
> DoSomethingWith (item);
> }
> catch (Exception e)
> {
> LogExceptionSoT heWholeProcessD oesNotStop(e);
> }
> }[/color]

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

--
Jon Skeet - <skeet@pobox.co m>
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]

Re: Code analisys ...

> My point being that the catch'es can be stacked...[color=blue]
>[/color]

True, and a good idea sometimes. I sort of mentioned that, but it is buried
in my reply:
[color=blue][color=green]
>> 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.[/color][/color]

--
HTH,

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

"Scott Coonce" <sdcoonce@gmail .HEY_YOU.com> wrote in message
news:%23xgMBQa1 FHA.1252@TK2MSF TNGP09.phx.gbl. ..[color=blue]
> 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(IOExcepti on ioex) {
> // do something to clean up io
> }
> catch(ArgumentN ullException) {
> // code to handle ArgNullEx
> }
> ...
>
> My point being that the catch'es can be stacked...
>
> Scott
>
>
>
> "Kevin Spencer" <kevin@DIESPAMM ERSDIEtakempis. com> wrote in message
> news:ePXWS7Y1FH A.2792@tk2msftn gp13.phx.gbl...[color=green]
>> 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" <pcmigel@priv1. onet.pl> wrote in message
>> news:%23S57$wW1 FHA.4032@TK2MSF TNGP15.phx.gbl. ..[color=darkred]
>>> ... 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(p FileName);
>>>
>>> XmlSerializer xS = new XmlSerializer(t ypeof(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 ...
>>>[/color]
>>
>>[/color]
>
>[/color]

[Scott Roberts]

Re: Code analisys ...


"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1dc215 33e7560d3698c96 e@msnews.micros oft.com...[color=blue]
> Scott Roberts <sroberts999@no spam.yahoo.com> wrote:[/color]
[color=blue][color=green]
>> try
>> {
>> Save_some_chang es();
>> Commit();
>> }
>> catch
>> {
>> Rollback();
>> throw;
>> }
>>
>> Very common, Very correct.[/color]
>
> Hmm... I prefer:
>
> try
> {
> SaveSomeChanges ();
> Commit();
> committed = true;
> }
> finally
> {
> if (!committed)
> {
> Rollback();
> }
> }[/color]

We'll just have to agree to disagree there! :-)
[color=blue]
> 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 :)[/color]

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

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]

Re: Code analisys ...

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