Month: August 2007

I had a quick look at the managed code analysis (FxCop) rules the other day to see what’s new and what’s been removed.  Unfortunately, one of the analysis engines wasn’t able to be “resurrected” in time for the release, so there’s a few really useful rules that haven’t stayed with Beta 2 the reslease of Visual Studio 2008.  Fortunately, there have been some additions too.  Fortunately, there is not a deficit, we’re up by 12 new rules. Following are the new rules: DoNotRaiseExceptionsInUnexpectedLocations NormalizeStringsToUppercase SpecifyMarshalingForPInvokeStringArguments SpecifyStringComparison UseOrdinalStringComparison AvoidUnmaintainableCode ReviewMisleadingFieldNames AvoidExcessiveClassCoupling IdentifiersShouldBeCasedCorrectly IdentifiersShouldBeSpelledCorrectly IdentifiersShouldDifferByMoreThanCase IdentifiersShouldNotContainTypeNames OnlyFlagsEnumsShouldHavePluralNames ResourceStringCompoundWordsShouldBeCasedCorrectly ResourceStringsShouldBeSpelledCorrectly MarkAssembliesWithNeutralResourcesLanguage RemoveEmptyFinalizers CatchNonClsCompliantExceptionsInGeneralHandlers … Continue reading Visual Studio 2008 Managed Code Analysis

Continuing the theme of Thead.Sleep is a sign of a poorly designed program, I’ve been meaning to provide similar detail on Thread.Abort and not just allude to it in other posts like ‘System.Threading.Thread.Suspend() is obsolete: ‘Thread.Suspend has been deprecated…. Many of the concepts I’ve discussed regarding Thread.Suspend also apply to Thread.Abort, and in much the same way that the ability to terminate a thread has existed for so long that the concept has remained ubiquitous when dealing with threads and it just keeps getting implemented without thought.  Thread.Abort is far more unsafe than Thread.Suspend; but, unfortunately Thread.Abort has yet to … Continue reading Thread.Abort is a Sign of a Poorly Designed Program

There is often a requirement for an application to log unhandled (and sometimes “handled”) exceptions.  This logging could occur to a log file, to the Event Log, a logging server, etc.  There’s great reasons to log exceptions but logging exceptions can be fraught with problems. I’ve have many clients that have been requested to log exceptions and simply threw (pardon the pun) in a call to some logging method in every catch block and added catch blocks around most code that could throw.  This certainly gets the exception logged but introduces at least one problem: if it’s an unhandled exception, when … Continue reading Exception Logging