Derik Whittaker

Syndication

News


Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Fail Fast Principle

I am thinking about posting about different principles/patterns over the next few weeks/months.  I have decided to start with Fail Fast.  This is something that I think most people over look or plain just don't do.

Although the concept of Fail Fast is easy and straight forward, in most systems I have seen it is rarely ever used or followed.  The underlying concept of Fail Fast can be summed up as follows.  Design your system or code so that it will check for and report any possible failures and report them as soon as possible.  Testing your code for failure points will lead to better, safer, more reliable code.

When adding your failure checks it is best to try to think about how the code can fail.  Think about what the error message/stack trace will look like.  If by adding the failure checks the message will become clearer and easier to debug, add the check.  If the check will not make for a better message or make debugging simpler maybe you don't add the check.

What does a system do that does not Fail Fast?  Fail often is my answer.  Most systems that don't attempt some sort of Fail Fast will work around failures.  These work around's can be as simple as 'defaulting' values from config files if the value is missing.  These could also be as outlandish as accepting bad data via a web service, trying to fix the data, failing and not reporting back the failure to the caller of the web service.

Few Fail Fast techniques I follow:

One of the things I like to do for my failure checking is to check parameters on public methods.  I like to add asserts to the top of my method to check to make sure the params are valid.  Valid could be Non-null (yes I know you could let the runtime throw a NullRef Exception, but I like constancy), valid string lengths, numeric's are within valid ranges, etc.  By performing these checks before I perform a single line of code, I feel safe that my code will execute later on in the method.

Example 1 on checking params:

 
Example 2 on checking params:

Another thing I like to do is check values that are returned from outside calls from within my methods.  Lets say I have a method that calls out to another method to return me an object.  I like to make sure that the object returned is valid, and if not throw a failure exception. 

Example on checking return values:

If you try to follow Fail Fast you will find that your system may 'fail' more during the initial development, but as you move forward your application should be cleaner and more stable. 

 

Links:

Martin Fowler on Fail Fast - Here
Wikipedia on Fail Fast - Here 


Posted 06-08-2007 1:08 PM by Derik Whittaker
Filed under: ,

[Advertisement]

Comments

joeydotnet wrote re: Fail Fast Principle
on 06-08-2007 2:32 PM

Yep, really what you're describing here is the essence of Design-by-Contract (DBC).  Very good way to write code, especially if you're not doing TDD and/or don't have any unit tests.  I'm hoping to be more diligent about practicing DBC on my future projects.  

Up until now, I've mostly relied on the fact that I literally don't write any code without practicing TDD/BDD.  But like you've pointed out, that doesn't adhere to the Fail Fast rule when the system is actually running.  Shame on me...  :)

Here is a very nice looking DBC mini-framework in C# that I'll probably use very soon...

http://www.codeproject.com/csharp/designbycontract.asp

Derik Whittaker wrote re: Fail Fast Principle
on 06-08-2007 2:37 PM

For the argument checking stuff, i am pretty sure you could use policy injection with the validation application block.  

But i am not 100% sure on that.

joeydotnet wrote re: Fail Fast Principle
on 06-08-2007 2:55 PM

Yeah, probably.  Or using any other AOP solution for that matter (i.e. Aspect#).  Guess it comes down to how explicit you want to be.

From what I've heard about Spec#, this kinda stuff will be more declarative in nature, which sounds nice.  Maybe like the Eiffel of .NET?  :)

Derik Whittaker wrote Simple extension methods to help with Asserting values
on 04-10-2008 8:49 AM

In the past I have written about the Fail Fast principle.  This is a principle I try to live my

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)