the corner office

Dont check it. Dont comment, and dont apologise. Thats what I do ;o)

Seriously, it is: if null gets passed in, then the issue is with the code invoking the method  the checks should happen *there* in my view, and so your method should just stop dead. Im all for defensive coding, and in a previous life I would have tested the passed-in parameter, but now I dont  too much spaghetti code.

Crash early!

I think it depends on what the method being invoked is doing. If it's supposed to use the object passed in to do some work, you have to revisit the biz rules and figure out if null is an acceptable input. If it's clearly not, I say throw an exception and leave it up to the code invoking the method to handle it :-) You've done your bit. Not sure about just stopping dead. I believe an app should just quit as soon as an exception is thrown because there's no such thing as an "expected exception" in my view. Clearly the proper flow of execution is buggered, so die app, die gracefully, but still die.

Dying and dying early and loudly is definitely the right answer - I don't believe in polishing turds ;), I guess the how can be tricky. I think there are 3 factors:

1. Will things break if an invalid argument is only found to be so after changes have been made? Will it break the atomicity of a method or operation? If it will, make 100% sure everything is dandy up-front.

2. Who will use the code? If the method is part of a more public API then the "professionalism" of it needs to be higher - and you need to idiot-proof your code more. Users need to trust you more and you need to trust users less.

3. My own preference is to differentiate in whichever way between exceptions which indicate problems I've anticipated and thrown m'self, and those which indicate a bug or problem in my code that I obviously haven't anticipated. It allows one to identify the source of a problem more quickly and easily.

The fun part is reconciling those 3 though :)

Generally I like the C style of return values.

something like:
boolean bSuccess = dodgyMethod(myNullObject);

Then test for success. I don't like how you put multiple statements in a try/catch and if any one of them fails you dump out. Also if you try to individually catch each statment the code is very messy and hard to follow due to the proliferation of try/catch blocks.

try/catch is sometimes useful though and I like that Java allows you the choice to pick ;-)

There's a bit of a discussion here: http://www.joelonsoftware.com/items/2003/10/13.html