Boy Meets World

Mike is currently…

snowboarding in Banff

[ subversion book ]

obligatory book plug

[ syndicate ]

rss 2.0 feed for boy meets world

[ contact ]

drop me a line

[ about ]

this is mike mason's weblog

[ eskimoman.net ]

original web pages

Sat, 03 Jul 2004

This is an archived blog post. I've switched to using WordPress as my blogging software and have not migrated all my old posts. I believe strongly in not letting an old link die, so this page continues to work. Please do visit mikemason.ca/blog to read newer posts.

Null is bad, hmm-kay?

Null is pretty much the bane of my existence right now. I’m doing Struts-based web apps and yeah, null is pretty much the only way to represent “don’t know” or “missing” when stuff is coming in from the UI. Problem is, people seem to take the nulls from the UI and litter the rest of the code with them.

Dan North puts it quite simply when he says all code should be a “good citizen”. That is, code should never expect, handle, or return a null value. This makes good sense, because it causes code to fail fast. Instead of a null floating around in your system, eventually breaking something that doesn’t have a ton of null-checks in it, a null-pointer exception will get thrown immediately at the source of the error.

Fail-fast applies to other stuff too. For example, when I’m writing tests, I’ll often think of a new one but not want to implement it yet. Instead of leaving the body of the test blank, I’ll write

    public void testShouldSellWhenPriceIsAbove100() {
        fail("write the test");
    }

This way, if I forget to actually go write the test (and for some reason I’m failing to review my changes properly before checking in) I’ll break the build fast and know about the problem.

When testing code using mock objects, you’ll often use dependency injection to pass mocked out interfaces to the class under test. If you add a new method to those interfaces, you’ll need to at least write an empty method body in your implementing classes, or the code won’t compile. Trouble is, you’re not trying to test the dependencies right now, so won’t want to write a real implementation. Instead of leaving an empty method body, try throwing a “not implemented” runtime exception.

This will get your code to compile, get your tests passing, and you can probably even check in the code that throws the “not implemented” exception. If any client code tries to use it, you’ll get that exception straight away, and your application will fail fast, at the source of the problem.

Posted 00:15, 03 Jul 2004.

[ permalink ]

[ tim bacon ]

musings of an xp coach

[ ian bourke ]

enhancing core competencies since 1976

[ martin fowler ]

a cross between a blog and a wiki

[ alan francis ]

agile != good

[ paul hammant ]

part of the problem…

[ darren hobbs ]

the blog formerly known as pushing the envelope

[ mike roberts ]

on life and technology

[ chris stevenson ]

skizz-biz

[ joe walnes ]

joe's new jelly

[ rob baillie ]

oracle

Registered plugins: SmartyPants, antispam, bloglinks (v0.2), calendar (v0+6i), pluginfo (v1.0), and userstatus (v0.1)
This work is licensed under a Creative Commons License.