One Issue on FxCop

One rule about catching exceptions is that you should catch a specific exception rather than a general one such as Exception or SystemException. With this rule, FxCop will show a critical error if you catch an Exception or a SystemException.

I'd like to catch an Exception in one case. If I write try/catch blocks, I first try to catch specific exceptions. In some cases, I'm not sure if my specific exceptions cover all the exceptions and I don't want that an uncovered exception faults out the method. In that kind of cases, I catch an Exception as my final catch. Breaking the rule like this is very useful if my method is in an infinite loop.

I'd like to see that FxCop treats my cases differently. If FxCop finds an Exception or SystemException, then it should check if a specific exception is catched before the general catching. If it does, then FxCop should display a warning instead of a critical error.

The Philosophy of Profilers

When you are writing a profiler, you can choose from two ways of collecting data: probing and sampling.

A probe profiler collects data by inserting probes or hooks into the application so the profiler runtime is called whenever the program executes that hook. It has the following benefits:

• The inserted probes will always be called when the application executes.
• Having a complete picture of the run
• Parent-child relationships between functions is guaranteed to be correct and the profiler can report perfect call trees necessary for you to easily find the call paths that took the longest time.

It has the following drawbacks:

• The instrumentation scheme can be cumbersome to use
• Since it's rewriting at the binary level, there's plenty of areas to introduce potential errors.
• Probes also take up space, resulting in some code bloat and slower performance.
• Slowdown makes almost impossible to run the instrumented binary on a production system

Sampling profilers take a snapshot of what's executing in the application at predefined intervals. VS Debugger is an example. It has the following benefits:

• Having far less overhead than probe profilers.
• Standing a much greater chance of using them on a production system without grinding the server to a halt.

It has the following drawbacks:

• It's entirely possible that all the samples taken of your application could show no code at all.
• Traditional sampling profilers that only grab the currently executing instruction for each thread make it much more difficult to determine the parent-child relationship between methods, so determining the worst performing code path is much more difficult.

Notes above are taken from John Robbins's article:

Make Your Apps Fly with the New Enterprise Performance Tool

All About Statics

The following are notes that I took by reading K. Scott Allen's article:

Get a Charge From Statics with Seven Essential Programming Tips

• An explicit static constructor results in code that performs worse.
• An implicit constructor has an additional metadata flag named beforefieldinit. This flag allows the runtime to execute the type constructor method at any time it chooses, as long as the method executes before the first access to a static field for the type.
• The runtime will stop any exceptions trying to leave a type constructor and wrap the exception inside of a new TypeInitializationException object. The original exception thrown inside the type constructor is then available from the InnerException property of the TypeInitializationException object. The second time you try to access a static property of the type, the runtime does not try to invoke the type constructor again, but throws the same exception observed in the first iteration.
• You should plan to catch any exceptions inside of a type constructor if there is any possibility of recovering from the error, and you should allow an application to terminate if the error cannot be reconciled.
• Avoid touching the static members of another type from within a type constructor.
• The CLR does not support the inheritance of static members. Nevertheless, both the Visual Basic and C# compilers allow you to touch static members of a base type through a derived type name.

Read Scott's article for more detail.

Static Classes in C# 2.0 and Abstract and Sealed Pattern

C# 2.0 introduces the static keyword at the class level. If you apply the static keyword to a type, then you cannot declare a variable of the type because it is marked as a static class. You also cannot derive from the type, or add any non-static members to the class. So a static class does the same as we apply the abstract and sealed pattern discussed in the last post.

Abstract and Sealed Pattern in .NET

The CLR doesn't allow types to be marked as both Abstract and Sealed. You can get around this by doing the following.

public sealed class AbstractAndSealed
{
private AbstractAndSealed()
{
}
}

In this way, no instances of the type can be created. I call it the abstract and sealed pattern. You can use this pattern when you are designing your own type that contains only static members. Examples are System.Console and System.Math.

I learned the abstract and sealed pattern from Jeffrey Richter's book

Applied Microsoft .NET Framework Programming