Re: NullPointerException

> I said that in response to the concept that it's somehow implicitly more
> reasonable to assume that a reference is non-null than to make any of
> gazillions of other assumptions

It is only more acceptable because it is more normal. The fact that it
is normal is the reason why NullPointerException is not only a
beginner's bug.

> You're telling me that you AREN'T advocating these techniques?

I am advocating them, alongside other techniques, in my work. As I
said in another post, the wikipedia page was just a bin for some ideas.
As such, I'll revise it (I already have a little).

> Incidentally, it's been demonstrated several times that your techniques
> are insufficient to prevent NullPointerExceptions.

Are you referring to the fact that it's possible to read from a final
field before it has been assigned to? If so, then hopefully there are
static code analysers that can pick that up.

You seem to think that one badly-implemented class is less complex than
two well-implemented classes. Numbers of classes and complexity aren't
necessarily proportional. The implementation classes could both be
package-private, accessed by a static method of some utility class.
The API user wouldn't know or care.

>1. It was returned from some API.

null returned from an API might be documented, but if it's possible for
programmers to forget to check for it, then some of them will.
Infinite Monkey Syndrome.

> 2. It was passed in from somewhere as a parameter.

That's unlikely if the 'somewhere' either followed these rules or was
considerate.

> Some fields are, sure. I agree that they should be declared as final.
> That's not what you said in the article, though.

And here we come to the crux of the problem. The article was about
preventing NullPointerExceptions. It wasn't about rules you should
follow absolutely in all your Java code. It was pretty terse, yet tone
was read into it.

"People who don't drive cars run people over less" is a perfectly sane,
if useless statement.

"You will run less people over if you don't drive a car" is equally
sane, but tone will be read into it. It will be taken as an insult,
and someone will respond with "but I live 40 miles from work" or
something.

The article didn't proclaim to be useful for all Java code, it only
gave some rules for preventing NullPointerExceptions. It didn't even
purport to prevent ALL NullPointerExceptions, which is another bit of
tone you read into it. It didn't say you should use it.

if (file.isDirectory())
{
File[] files=file.listFiles();
System.out.println(files.length);
}

That is capable of throwing a NullPointerException. This is fairly
pedantic, but it is possible. The real directory could be deleted and
a file created with the same name between the call to isDirectory() and
the call to listFiles(). So you still need a null check.

If you trust your developers to check this possibly null value, then
fine. But it's more likely that they'll read the API and believe that
the above code sample will work always, which it won't. However, if
you force them to catch a checked exception then they can't forget as
easily. Is this a significantly higher level of abstraction, now that
I've demonstrated a potential bug?

MyUtils.listFiles is a valid name, because the name doesn't have to
include the types of exception something throws. The name will be
backed up by documentation anyway, so the only requirement is that it
is descriptive enough to be useful.

> Quite the contrary, if you had concepts that would take the maintainer
> weeks to understand

In this case I meant concepts that added very little but were complex.
I struggle to think of an example.

Wordiness of exception-handling code is ok, because it is not a
potential source of bugs itself, unless the developer gets fed up and
just whacks 'throws Exception' everywhere, which is an issue of its
own.

I'm undecided on checked exceptions, and hardly ever use them myself,
but I think that where the developer might neglect to read
documentation, a checked exception will force the issue. That might be
good, it might be bad, depending on your preferences, but in terms of
bugs, it should result in less, because it at least forces the
developer to think about, or notice, the possible exception.

I like the non-null language extension idea. Someone else was
discussing it today in terms of annotations (not on Usenet).

> You seem quick to back off those ridiculous
> contortions when someone points them out, yet there they remain in
> imperative language in your essay.

Again, I'll be updating that page at some point, but I feel like I
should see where this leads before I do. I have an open mind, much to
my annoyance.

.

Relevant Pages

  • Re: Exception as the primary error handling mechanism?
    ... and reduced defect rate against machine efficiency too. ... example of an API that is simply poor: ... exception than it is to make unnecessary tests. ... more complex code, lowered readability and usability, and more defects, ...
    (comp.lang.python)
  • Re: Exception as the primary error handling mechanism?
    ... Does this imply that putting code in functions is a poor API? ... exception than it is to make unnecessary tests. ... The difficulty for the API designer is to make ... caller and can extract a performance penalty that may be unacceptable ...
    (comp.lang.python)
  • Re: usercontrol with readonly property that can be set at design t
    ... time via the designer, the exception worked wonderfully. ... If the developer tried to set the value elsewhere in code, ... Public Property WizardPageNumber() As Integer ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: Advantage over VB ?
    ... sensitivity a slight annoyance, but quickly adapted. ... are a multi-language .NET developer you would probably favor the inverse. ... world that VB.NET is a "toy" language and/or that it is not for "serious" ... In VB.NET you ahve to catch the exception to ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Exception as the primary error handling mechanism?
    ... In the article API Design Matters by Michi Henning ... In many language implementations, exception handling is expensive; ... the caller will treat the condition as an unexpected ...
    (comp.lang.python)