Catching generic exceptions

[steve bull]

I am trying to make my code conform to FXCop standards. The problem I have is when, for example, I try to catch errors generated by
creating an instance of XmlTextWtriter FxCop insists that I only catch named exceptions. I can add clauses for all currently known
exceptions, ArgumentNullException, ArgumentException, ArgumentOutOfRangeException and InvalidOperationException - but if a new error
is generated in a future version my code will never know about it.

Is there a recommended way of dealing with exceptions like this? A final catch clause will not give me any exception information.


Thanks,
Steve

 

[Jason Newell]

Steve,

System.Exception is the base exception class. It is the only way that I
know of to catch any non-named exception.

Jason Newell

 

[BravesCharm]

try
{
//code
}
catch(Exception e)
{
// will catch ALL exceptions.
}

 

[steve bull]

I realize I can catch a generic exception but FxCop - Microsoft's standards as I understand - generates a "Do not catch general
exception types" error/warning. I do not understand what they expect you to do - ignore unexpected errors?

 

[Michael Höhne]

I do not understand what they expect you to do - ignore unexpected errors?

Well, depending on the type of code where the exception is thrown, the
answer may be yes. I think that the FxCop warning states somethng like "it
is usually ok to catch System.Exception in UI applications", because you
have to display the exception in a user friendly way. However, if you catch
exceptions in a other pieces of code that are non-GUI applications or do not
provide any error logging, any unexpected exception should be propagated to
the caller. The first caller in the call stack then is responsible to
display the exception message or log it to the event log.

I think that it's nearly impossible to conform to all rules made by FxCop,
though some of them are pretty good to find code that can be enhanced. In my
opinion the best way to deal with such warnings is to split your code in
smaller pieces, so that the UI applications (or whatever application it is
making the first call to a method that may throw the exception) only contain
UI-related stuff and all of the needed processing is done in separate class
libraries. This allows you to ignore the specific warnings only in the
projects where it makes sense, but you can go on to keep them in other
projects. However this adds some extra cost to your development. I tried
FxCop and decided to not use it anymore because it overcomplicates
development, though I sometimes launch it to find some places I forgot (like
string constants that should go into resource files, because I usually have
to write localizable applications).

Michael

 

[steve bull]

it sounds reasonable. Partly I just wanted the ability to log what the error was that occurred. But, it is a useful tool
even though I have found a few of the rules which are just wrong for what I am doing and they have helped to unearth a
few bugs which would have been difficult to find. So, I plan to get the number of errors to a workable number so I can
continue to use it.


Thanks for the input it is interesting to hear of other peoples experience with FxCop.

Sorry I have been rather late in replying. Once I started working on something else I didn't really get chance to reply
sooner.


Steve