Catch/Rethrow

How often do you see this pattern (or variations on it)

try{
…some code…
}
catch{
throw;
}

Sometimes it will be catch(Exception ex) or catch(SomeParticularException ex), and sometimes it will be throw; or throw ex;, there is no finalizer block, but the important thing is that NO OTHER ACTION IS TAKEN (no logging, no retry, nothing else in the catch block).

As far as I can tell, this is equivallent of wrapping code in NOP (no-operation) commands.

Please don’t do this.

Moving back to Lunarpages from Webhost4life

Well, 4life turns out to be for about 2 or so years.

Webhost4life’s crimes:

- Fuzzy method of measuring if you are taking your fair share of resources on a shared computer (Lunar pages at times is guilty of this too according to many online reviews, although on my linux account, I never ran into that)

- Crappy in person service (Lunarpages may be guilty of this, but I’ve had so much less need to deal with lunarpages people, their software up to now has served all my needs)

- Overloaded and underpowerd machines (My short Lunarpages windows account had this problem, too, but as a hobbist running small sites, that isn’t really a problem)

So why am I going back to Lunarpages?

Automated Testing Using WebClient and HTML Agility Pack

I researched options for testing my ASP.NET website. I decided to use Scott Hanselman’s solution where simulate IIS using Cassini and simulate a browser using WebClient.

Good Points
It works!
It’s free!
Doesn’t require a massive refactoring or rewrite.

Challenges
Cassini should be a singleton. Unless you are testing something that is IIS dependent, you should not destroy Cassini inbetween each test or test fixture.

.NET Attributes to use more often

My theme here are general purpose programming attributes, ones that you might use for any class.

(first seen here)

DebuggerStepThroughAttribute, [DebuggerStepThrough()]
You can still set breaks here, but normally the debugger will fly right over it. Use this when you find yourself running through the same boiler plate code over & over again, especially if the code is machine generated, or otherwise not of interest.

DebuggerNonUserCodeAttrbute.[DebuggerNonUserCode()]
No step through, no breaking, even if you have a breakpoint.

[DebuggerDisplay(

Built in Exceptions you should use

I’ve been using FxCops which looks down on “throw new Exception();”

Here are some more narrow exceptions that already exist in the framework that you should throw, hey it saves you the effort of writing a custom error class.

ArgumentNullException – Argument is null
ArgumentException – Argument not valid
ArgumentOutOfRangeException– arguement too big or small, or not on the list
ArithmeticException — The root of a negative number
InvalidOperationException -given state,