I was quite impressed to receive the publisher's response to my list of errors in the text of the book "Professional Techniques for Digital Wedding Photographers, 2nd edition". I'll paste it below...

From: Photobook@aol.com
Date: 4 January 2005 18:31:48 GMT+02:00
To: wn@photudio.co.za
Subject: From Amherst Media
Dear Waldo,

Thanks for your careful review of the Hurter book and for taking the time to bring the errors to our attention. We will bring your comments to the author's attention when the book is reprinted.

Best Wishes,

--
Barbara A. Lynch-Johnt
Assistant Editor
Amherst Media, Inc.

I have just now received an SMS from Chas Everitt - the estate agency. But first some background. I recently (2 months ago) sold my old home and bought a new one. The old one I sold through Chass Everitt, the new one I bought directly from Urban Constructions - the developers.

Anyways, the SMS promoted a new townhouse for sale - as if I am interested!!!!! I mean - I just spend the most money I have ever spent on a new house - barely 2 months old, and now they want to sell another house to me? This is down right stupid, blind and irritating.

Sounds like a paradox? Nope - I don't think so. What does it really matter if you are brilliant at your work in the IT industry, specifically?

You would expect to receive more clients by the day, always being overbooked and people would fall over their feet to get you to do their projects. Especially if you are way under priced.

However, real life has taught me that politics, relationships, smoke and mirrors and FUD for change significantly skews this idyllic opinion.

When should you perform input validation, and how thorough should you be? This is a question many developers are struggling with.

This ties back to one of my earlier comments on defensive programming techniques. However, here I will present a more detailed example. Most competent developers will perform the basic input validation to ensure correct input, such as ensuring a date has the correct format, an age is positive etc. However, should you explicitly add a check in your code for null values? Java will generate a NullPointerException in most cases when performing an operation such as method invocation on a null object.

There are two reasons why I prefer to explicitly check the input when data is passed to a method from an external party. Firstly, I do not trust the third party, be that another developer making use of my API, or myself using a class from another package. Secondly, if a null value slips through, I need to show to the world that I have considered such a scenario, and that I have actively coded to handle it. If I depend on NullPointerExceptions to be thrown, I might just one day discover that the API I am using has a side effect that it does not properly handle null values, and thus return nonsense.

I am pretty sure once you transcend the youth phase of software development, and you start thinking about what you are actually doing whilst writing code, you'll start running into tough decisions such as when to throw an exception, and when to return null.

I found a simple way of resolving this controversy. Before answering that question, you need to ask yourself "Would it be beneficial to the caller if the code throws an exception or would it be more beneficial if I return null". This refers both to the code and the programmer. I say this since returning null is generally regarded as a Bad Thing, since the onus is on the developer to ensure the return result is checked. However, there are scenarios in which it is better to return null.

Lets focus for a moment on framework design. This is a bit different since many people will be using your code and be absolutely dependent on the way you return from the function call, whilst writing application code you normally tend not to invoke a method that regularly, thus if you made a mistake it should not be that terrible.