I’ve finally pulled my finger out and written an FxCop rule to pick up code like:

try
{
// do something
}
catch (Exception ex)
{
// do nothing
}

this pattern shows up all the time in some code i have the pleasure of dealing with in my day job, normally at the end of a day-long search for the cause of some weird, intermittent behaviour that just started happening the day before a release is due. running it against our (inherited, thankyou) codebase found 443 occurrences. a quick random sample leads me to think about 80% are really nasty bug-obscuring usages, and the rest (~20%) are legitimate.

the rule implementation is not perfect – there still may be false negatives, and a “positive” doesn’t always mean something’s being done wrong, but I do think it’d be worthwhile to incorporate this rule into the fxcop runs everybody's using on all their projects because they're just that professional, goddamnit.

FxCop generates a report for you, and launches VS.NET’s editor on the individual line of source code where the problem occurred, which is hot, as far as I’m concerned.

I’ve uploaded a zip with the project that generates the rule assembly, and the rule assembly itself. You need to install and run FxCop 1.32, add the rule assembly, and then analyse the target assemblies. The project should be useful as a template for implementing new rules; there are a few fiddly bits which need to be gotten right to avoid obscure object reference not found exceptions in the FxCop UI down the track. Some nice references I made use of: 1 | 2 | 3 | 4

Hope this is useful.