I like to code as little as possible.

I am not referring to how much time I spend coding, but more how terse and compact ("neat") the code is. If it's growing hairs trim them. If it's more than one complete thought, extract method.

One thing that's been causing me to grit my teeth a lot lately seems to be caused whenever I hear the term, "error handling," usually like, "look at that code! it's crap! There's no error handling!" where, in my opinion, error handling has no business being. It hurts even more when the person is someone I respect and otherwise agree with on all matters technical.

Extraneous error handling seems to me to be one the fastest ways for code to go from simple and clean:

to stressed out and hairy:

For a long time, when I first started learning .NET, I had this C++/COM baggage I brought with me, where I thought HRESULTs and IErrorInfo was the right way to do error handling. I had brief experience working with java and remember being shocked at how some java programmers thought the ratio of "catch" to other keywords in their programs should be approaching 1:1. I had concluded that "try" was bad, and .NET was worse off because of it.

Then I read what the P&P Team thought about the exceptions and breathed a sigh of relief. I had my strategy:

Exception Propagation

There are three main ways to propagate exceptions:

• Let the exception propagate automatically

  With this approach, you do nothing and deliberately ignore the exception. This causes the control to move immediately from the current code block up the call stack until a catch block with a filter that matches the exception type is found.

...

(emphasis mine)

This is how I think 99% of code should handle exception, just as it's how I think 99% or bystanders should handle high speed car chases. Don't do anything! Let someone else who knows what they are doing handle it.

For this to work, you often need to alter other bad habits as well, such as instead of "try { DoSomethingToFileThatMightNotExist(fileName); } catch (FileNotFoundException) { /* ignore */ }" say "if (File.Exists(fileName)) DoSomethingToFileThatMightNotExist(fileName); }".

This also helps with debugging. Who likes it when you turn on "Stop when exception is thrown" in the debugger only to find there are a gazillion exceptions you don't care about being caught by code that ignores them?

All this leads me to see "try" as a code smell. I look extra hard at code with "try" and even harder at code with "catch". If I can, I refactor them away as quickly as I can.

Ideally, a user facing program should have only one place where errors are handled: the place where it decides how much to show to the user and how much to report to you via some other channel.

This helps me keep my code small, neat, and clean.

I always kind of wondered how this checkbox in task manager works:

Today, while checking to see if I left Image File Execution Options\Debugger on for some program that is broken on my machine, I noticed this:

Now I know.