Fail Fast and Debug Fast

Martin Fowler's blog has a great post today on the technique of failing fast. I have the following comments to add:

1. Many times I am split in whether to fail fast or slow in my own coding. Some times I choose fail fast, some times fail slow. Now I think I am always going to choose fail fast. This post has clear arguments for it that I completely agree out of my own experience.
2. I have been trying myself to include as complete information as possible in an error message to help pinpoint the cause, which has proven to be very helpful. The post advocates the same.
3. Most developers think the debugger is our best friend. It's not. Using debugger is a very slow way of finding what's exactly is going on when something goes wrong. The quickest way is a stack with enough information (such as 1) a synopsis of the situation and 2) the values of local variables). The former I always try to include in the exception I raise. The latter cannot be done automatically. If you cannot figure out the cause of the problem by the former, it's when you will need the debugger but then you need to reproduce it.

The quickest way of debugging is always you see the stack and the synopsis, you know immediately what's wrong and you fix it without having to reproduce it in the debugger. Fail Fast is one good technique that helps you do that.