Re: Checking for null parameter

On Mon, 9 Jun 2008, Lew wrote:

pek wrote:

So, is this all necessary? I mean, if A, Devil, Fire and Angel is null and I know that they should not be, then that means that I have an error in my code. There is no reason to explicity tell someone that the object should not be null. If I do, I have to try catch almost 80% of my code.

What do you think? If checking for null overkill or not?

A method must be coded to handle any input that can be sent to it. Otherwise it will break when it gets the wrong input.

This is very silly advice.

What's the matter, is it too hard to copy-and-paste a try-catch block?

Around *every* *single* *method* (or code block, or whatever granularity you fancy)? Yes. Yes it is.

What you have to check in private methods is different from what you have to check in public methods, on account of you completely control calls into private methods but not others.

This is the crux of it - some methods do need hardening against duff parameters, like nulls, NaNs, out-of-range integers, objects that are invalid in more subtle ways, etc, but not all. You say all public methods, but i think that's overkill. Firstly, it only needs to be on exported methods - methods that you expect outside code to call; the main entry points to the component or package or whatever. If outside code wants to call your internal methods with duff arguments, fine, let it handle the consequences. Secondly, i'm generally quite happy to have code screws up when given a null, as long as it's clear that i shouldn't pass a null. That again hands the responsibility for not passing in a null to the caller.

It would be nice if java could express a requirement for non-nullity in the type system. Some type systems forbid nulls from normal variables, and if you want a variable that can be null, you have to call it an "Option<Foo>" or something. I quite like this idea - most variables shouldn't be null, so make that the default, but provide a way of having them be null when that's okay. A simple syntax would be a question mark after the type - implying it might be one of those, or it might not:

String foo = null ; // compile-time error
String? bar = null ; // that is okay
String baz = bar ; // also a compile-time error - can't assign from ? to not-?
String qux = (String)bar ; // okay, albeit icky

That's probably in Scala or something.

Hey, maybe we could use ! to mean const. HHOK!

tom

--
Kein Mehrheit Fur Die Mitleid
.