That depends entirely on the situation. If the "null" is likely to be a programmer error, or if returning null would require the caller to check the result for null, then the exception is the better choice: it forces the problem to be fixed quickly, and obviates the need for the caller to check the result for null.
If, on the other hand, passing in a null is something you expect to happen innocently, and a null return value wouldn't be harmful or is one of the expected possibilities anyway, then returning null might be OK.
That all depends on what a return value of null means for your method.
For example, if you may have null returned ligitamately from the method for some other reason, then if you return null when the precondition is violated, clients will not be able to distinguish between violations of a pre-condition, and simply getting a null value returned.
Typically, if the client has violated the pre-condition of your method, then it should throw an exception to be caught by the client, because if the pre-condition is violated, it indicates that method execution cannot proceed. Whereas if you return null, the client may assume that the method returned null as the valid return value of the method for the given parameters.
I would say that the only time you should return null JUST because the parameter was null is if it logically makes sense that your method should be able to operate on a null parameter, and that operation should produce null. In this case then, checking that the parameter is null is not actually a "pre-condition", it's just one of the steps required to produce the valid return value.
So to give a definitive answer to your question, if it really is a precondition that the parameter not be null, because your method cannot logically operate on a null value, then the correct response is to throw an IllegalArgumentException, which signals to the client that a pre-condition was violated, as opposed to signalling that the particular parameter just happened to cause the method to return null.
As a further note, this will also make applications easier to debug. Returning null could cause a null pointer exception to be thrown at a LATER point in the application, when the class is doing something completely unrelated to your method. That sort of error is very difficult to debug, because you need to then figure out when a reference was set to null, and why. Better to throw an exception in the method that has violated pre-conditions, so it's easier to debug. This is known as Fail-Fast Behavior.
An even worse situation can occur if the program does NOT later throw a NullPointerException, but instead continues to erroneously operate on null values where non-null values should be required, because all of the methods invoked check for null parameters and just return null instead. You can have unexpected/undefined behavior without NPE's, and never know why they have occured. Or the variable that throws the NPE was not the variable that was ORIGINAL set to null through a pre-condition check, but rather was set to null due to a pre-condition check on a variable that was ALSO set to null due to a different pre-condition chekc, and so forth, going back through several variables. That sort of situation would be a real mess to try to debug.
Geeze, why not just ask the meaning of life or something simple ...<g> IMHO, FWIW, your mileage may vary, etc: Throwing an IllegalArgumentException is not very different from allowing the method to proceed and then (assumedly) failing later with a NullPointerException. I say that because both IllegalArgumentException and NullPointerException are (direct) derivations of RuntimeException, so unchecked. Admittedly though, throwing the IllegalArgumentException is semantically more correct. Regardless, one of reasons for RuntimeException being an unchecked exception is that the number of places where it (and its derivations) can occur is enormous and can't be reasonably determined at compile time. From the Java Language Specification: "The exceptions that are represented by the subclasses of the class RuntimeException, for example NullPointerException, result from run--time integrity checks and are thrown either directly from the program or in library routines. It is beyond the scope of the Java programming language, and perhaps beyond the state of the art, to include sufficient information in the program to reduce to a manageable number the places where these can be proven not to occur." In other words, a really large portion of your code could be checking for nulls AND letting the NullPointerException occur or throwing it yourself is consistent with the core libraries. So, once again IMHO and FWIW, I'd lean toward checking and returning null given those two choices. Given any choice I'd let the NullPointerException occur and have the calling method check for null if null was expected during normal operation.
The problems of the world fade way as you eat a piece of pie. This tiny ad has never known problems: