Checking for null parameter

[Ulrich Eckhardt]

By checking for it first, you can fail gracefully, under full control.

But it definitely is under control. Other than in e.g. C++, where certain
actions invoke "undefined behaviour", trying to dereference null in Java is
well-defined and also works reliably.

I can imagine a case where it seems to make sense to first check for null,
and that is writing to a file. If you first open and truncate the file and
then write the changed recordset, you shouldn't touch the file if the
recordset was null. However, this is just an illusion, because if you go
for data integrity you also need to consider a full disk during write, and
then it doesn't buy you anything to first check for null.

By ignoring the null parameter, you crash your program all the way to
stack trace.

Right, you get a stack trace or an IDE might fire up the debugger at that
place, but I wouldn't call that a problem, there is not much more
information you could reasonably ask for. Of course, there are cases where
you wouldn't want to terminate the whole program but only the current
transaction, but that has to be considered anyway so the null argument is
not different to any other error.

The point of this stuff is to help you *fix* what's wrong. What good does
it do you to know something's wrong if you don't know what, where or how?

An NPE with the according stacktrace doesn't help you? To me, that is
usually enough to figure out what went wrong and where.

I think you have a very precise plan what you're doing, but the really
unfortunate thing is that you are not telling us. The only thing you are
communicating here is that alternative plans don't fit your goals and that
they are therefore crap. How about actually answering what
handleNullSituation() would do? Try to give examples!

Uli

 

[Ulrich Eckhardt]

Stack traces are messy and cause the program to crash. If you don't mind
your program crashing, nothing else I say will make sense.

Lew, have you ever considered that when you say "handling a null argument"
you mean something different than everybody else and that when you
say "crashing" it also means something different for everyone else?
Seriously, consider that and next time you post maybe get a colleague to
proof-read your text and when someone answers don't immediately assume you
understand and jump to conclusions.

Seriously, look at it, how many times in this thread did you feel
misunderstood? You even accused someone to make straw man's arguments, but
it is just that you are speaking a different language while being f***ing
arrogant about it. Someone even called you insane, while I would only say
that you have a lack of communication skills and empathy. I know that you
can't change that, but provided you actually are a programmer that is used
to just using the brain to solve problems with logic, would you mind taking
these deficiencies into account when posting? It actually would make the
communication here much more efficient and reduce the heat a lot, too.

Uli

 

[pek]

Exactly!

In this scenario, an external resource was not available, and deep down threw
an exception. Yet, somehow, the programmer felt that there was a way to
gracefully recover and give the user a dialog that makes sense.

No crash needed here.


But not when, hence the need to handle an exception.

What do you mean when? If you call a method that uses the internet and
the internet is not available, it will throw a checked exception.
That's when. Is there any way else?

Sometimes, even rarely.

What do you mean sometimes? It's a bug in your code, and bar is always
null.

I'm begining to think that you do not understand what kind of NPE I am
talking about. Look, I will check for null if I need to follow a
different path in my code

if ( foo == null ) { doSomething(); }else{ doSomethingElse(); }

But I will not check for null references in every method or contructor
if it doesn't make sense. Your connection example was a bad example
since you know that there is a case that a connection won't be
available. In this case, you use checked exceptions. I can't see where
this scenario fits the discussion. Where you thinking something like
this:

if ( foo == null ) {
saySorry();
} else {
foo.connect();
}

Even if you did, in this case, foo would be null because somewhere in
your code you forgot to instantiate it, or you did, but something went
wrong. Either way, foo will never work until you fix your bug.

So, instead of checking for null references in places where it doesn't
make sense, you don't even bother. You can catch the NPE in you main
method and that's it. As simple as that.

Different scenario from the one I proposed. Different scenarios naturally
will require different handling.

Agree, but I couldn't see where your scenario fit in this discussion.

public static void main(String[] args) {
try {
startProgram();
} catch (NullPointerException e) {

But there you are! You catch it! Excellent.

Yes, I never said you never catch NPE or leave your program to crash
like crazy. I was againt checking for null references. I would never
do what you suggested,

if ( bar == null ) {
handleNull();
} else {
bar.connect();
}

In my case, I will never check for null references.

I wouldn't put the dialog *in* the catch block!

I'd move up the ladder and set my result so that the controller knows to move
to the appropriate view.

totally agreed

The program *might* exit. It might not. Why are you so insistent that the
program exit?

agreed again.

 

[Jack]

Lew a écrit :

That's not how invariants work.


Invariants are inherent to an algorithm. If you don't find them, it's
because you haven't fully analyzed the algorithm. You don't just throw
away the whole analysis because you broke it - that's exactly the sort
of trouble invariant analysis is designed to help with.

'assert' didn't fail you, it was the other way around.

How can you be so arrogant ?

 

[Arved Sandstrom]

[ SNIP ]

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.

[ SNIP ]

It's probably in C# is what it's probably in. A nullable type in C# is
an instance of System.Nullable. Essentially these are value types. So you
can write (as a shorthand)

double? temperature = null;

See http://msdn.microsoft.com/en-us/library/2cf62fcy(VS.80).aspx

What Scala has is the Option class. Haskell has the Maybe type. These
fundamentally express either a valid value or nothing (Nothing, None).

AHS

 

[pek]

OK... Let me take you back to what was the meaning of this whole
discussion because I believe that the thing is going out of hand. The
discussion was about CHECKING a null reference, not HANDLING. Here is
an example:

public class ChatExample {
private Connection conn;

public ChatExample() {
// I intentionally forget to instantiate the conn
}

public void connect() throws ConnectionException {
try {
conn.connect();
} catch (ConnectionExcetpion e) {
// Delegate the exception
throw new ConnectionException("Connection failed in Chat",e);
}
}

public sendMessage(String message) throws ConnectionException {
try {
conn.sendMessage(message);
} catch (ConnectionException e) {
// Delegate the exception
throw new ConnectionException("Couldn't send message in
Chat",e);
}
}

class Connection {
public void connect() throws ConnectionException {
// Do socket connection etc. etc.
}
public void sendMessage(String message) throws ConnectionException
{
// Send the message using sockets etc. etc.
}
}
}

public class Main {
public static void Main() {
// Catch and log any exceptions that wheren't planned without
crashing
try {
startProgram();
} catch (NullPointerException e) {
// Log it and inform user
} catch (Exception e) {
// Same here (probably combining with the above exception
wouldn't have any difference
}
}

private void startProgram {
// Do anything
// At some point you want to send a message
ChatExcample chat = new ChatExample();
chat.sendMessage("Hello world");
}
}

OK, now, did you notice that I forgot to instantiate the conn
attribute? That is a bug, which means that the user can NEVER send a
message simply because it is a NPE and it will stay that way no matter
what. Notice also that I didn't try to check for it, for example, I
didn't do this:

if ( conn == null ) {
// log and inform
} else {
conn.connect();
}

Because I believe that if conn is null, it is a bug! And the program
doesn't work, so you have to fix it. You can check in main method for
NPE of any object in your program, thus avoiding checking them in
every single method.

Notice also that I didn't even check if the String message isn't null.
The same thing applies here, if it is null, that is a bug of the
developer that uses my code, so he has to fix it. I don't care for
checking a NPE. It is obvious that I need the String in order to send
the message. It is obvious in any case that a method that accepts any
object reference needs to be non-null. Otherwise I would state it in
the Javadoc (if the object is null, this method would behave like
this, otherwise like this).

So, to start from the beggining of this discussion, in my opinion,
CHECKING for NPE isn't necessary. If there is one, then that is a bug
and you have to fix it. If you want to log it you can, but you don't
need to CHECK it whether any object you are about to use is null or
not. Handling the NPE is another thing. In my example, I did handle
the NPE, but I didn't check it.

 

[Jack]

Lew a écrit :

Here's what I mean. Algorithms have invariants. When you figure out
the algorithm, you identify the invariants. 'assert' is Java's
mechanism to express and enforce those invariants. If you abandon
'assert' because you have trouble identifying the invariants, this is
not the fault of the keyword, it's because you made a decision as a
developer not to analyze for invariants.

Does that make more sense?

Yes of course.

But I was trying to show that most invariants are null/size invariants,
and they changes depending of the uses. So they are not "that" invariant.

Have you some precise example to show how they helped you instead of "if
(canBeDone) { /* do it */ }" , please ?

 

[Ulrich Eckhardt]

Lew a écrit :

How can you be so arrogant ?

That question aside (and I also find the way Lew writes pretty arrogant),
he's actually correct in this statement. If you have code that relies on a
condition and that condition is established e.g. in the constructor of the
class, that constructor either establishes or it doesn't return (i.e. throw
or downright abort). However, in the following calls to memberfunctions,
you only assert() that the conditions are met, you don't use proper runtime
error handling because it definitely is a programmer's error.
BTW: 'definitely' here means 'by definition', because that is how an
assertion is defined.

Now, if you lateron found that the assertions failed, but your code still
worked, your initial analysis was wrong. The reason is that the initial
assumption that the code _depends_ on a precondition was wrong, because the
precondition was broken but the code still worked. Of course, it can also
happen that your code only seems to work and will break under different
circumstances.

So, if I find a failing assert(), I actually check why it was there in the
first place and why it is violated now. It can happen that the requirements
have changed and that the assertion is simply wrong or needs to be updated.
It also happens that some other changes broke the assertion and then you
need to fix the other code.

Uli

 

[pek]

For this sort of thing, use 'assert':

  public class ChatExample {

    private final Connection conn; // final added

    public ChatExample() {
      // I intentionally forget to instantiate the conn

      assert conn != null;
    }

    public void connect() throws ConnectionException {
      assert conn != null;

      try {
        conn.connect();
      } catch (ConnectionExcetpion e) {
        // Delegate the exception
        throw new ConnectionException("Connection failed in Chat",e);
      }
    }

    public sendMessage(String message) throws ConnectionException {
      assert conn != null;

      try {
        conn.sendMessage(message);
      } catch (ConnectionException e) {
        // Delegate the exception
        throw new ConnectionException("Couldn't send message in
  Chat",e);
      }
    }

We assume some appropriate mechanism for invoking conn.close(), not shown here.

Now it is impossible to throw NPE.  Problem solved.

As for rethrowing the ConnectionException, that is controversial.  At some
point you should recover to correct program state instead of propagating the
exception.  Also, in real life of course one would log the ConnectionException.

I knew would stick in the coding and don't comment on what is my
point. I totally agree of the recover and stuff. BUT THAT IS NOT MY
POINT! Do better exception handling, do better recover, do anything.
BUT conn WILL STILL THROW A NPE no matter what. Even with the
conn.close(), this code will still throw a NPE. Why wouldn't it? The
attribute conn isn't instantiated, ANY method you call WILL throw a
NPE.

So forget about the way I programmed it (this is an example after
all). The point is that conn is null. And what I am trying to discuss
from the beginning of this thread is that YOU DO NOT HAVE TO CHECK if
it is or not. Not conn, nor any other object passed from a method
EXCEPT if there is meaning to it (if the program will behave in
another matter, and that DOESN'T include handling the NPE).

Am I not making my point clear? Is there any ambiguity in what I'm
saying?

You suggest (from your earlier posts) that the method connect() should
behave like this:
if ( conn == null ) {
handleIt();
} else {
conn.connect();
}

I say DON'T CHECK conn == null. You don't have to because then ALL
YOUR METHODS should check if ANY OBJECT of it's parameter list is
null, which is overkill. If an object reference was null and that
broke your code, it should be found in the testing period of the
program and fixed.

So, once more: I believe that checking for null references anywhere
other than where it makes sense, is overkill. And I'm ONLY talking
about NullPointerExceptions, not any other types of exceptions. Also,
a null reference making sense is when the method still does the job it
suppose to no matter what (I'm thinking Graphics.drawImage where the
image will be drawn even if you pass null to the Observer object).

 

[pek]

For this sort of thing, use 'assert':

  public class ChatExample {

    private final Connection conn; // final added

    public ChatExample() {
      // I intentionally forget to instantiate the conn

      assert conn != null;
    }

    public void connect() throws ConnectionException {
      assert conn != null;

      try {
        conn.connect();
      } catch (ConnectionExcetpion e) {
        // Delegate the exception
        throw new ConnectionException("Connection failed in Chat",e);
      }
    }

    public sendMessage(String message) throws ConnectionException {
      assert conn != null;

      try {
        conn.sendMessage(message);
      } catch (ConnectionException e) {
        // Delegate the exception
        throw new ConnectionException("Couldn't send message in
  Chat",e);
      }
    }

We assume some appropriate mechanism for invoking conn.close(), not shown here.

Now it is impossible to throw NPE.  Problem solved.

As for rethrowing the ConnectionException, that is controversial.  At some
point you should recover to correct program state instead of propagating the
exception.  Also, in real life of course one would log the ConnectionException.

Also, by what I see, you changed your code from

if ( conn == null ) {
handleIt();
} else {
conn.connect();
}

to

assert conn != null

WHICH IS STILL CHECKING FOR NULL!

 

[Ulrich Eckhardt]

I just mean doing something on purpose with it - that's common English.


Um, no. "Crashing" is when a program ends abruptly not through an
intentional exit.

So a compiler run terminating due to a syntax error is a crash? Not to me.
Not even if it was terminated due to an internal error not caused by the
input. A crash would be if there was no error plus a corrupted output file.

Did you mean something different from that?

To me, a program that terminates with a useful error message didn't crash.
The exception reason including the backtrace (i.e. the Java default
behaviour when an exception isn't caught) already qualifies as such.

Accused someone who actually was using a straw-man argument. "Even
accused" because they "even did".

*sigh* Using a straw-man argument is a tactic in order to 'win' an
discussion. I personally wouldn't accuse someone of a straw-man argument
when it is just a simple misunderstanding. Reread that posting, he was
actually responding to something you didn't say, but even to me what you
said seemed to imply that! So, is everybody but you unable to understand
what you mean or is maybe you who failed to express that?

Did you misunderstand anything I said?

Probably. You started off with "always handling null pointers" and lateron
said that one possible way would be to document that a function will throw
NPEs when passed null, which is exactly what happens if you don't code any
handling code. Exactly that is what _I_ would call not handling null
pointers. A simple example would really have helped!

And empathy for what? No one has expressed emotions in this thread; to
what should one be empathetic?

Empathy for the human beings on the other end? Just being a bit nicer and
understanding that misunderstandings happen and that not everyone agrees
with you and especially that not everyone has your background and therefore
not everyone is able to always understand you? Being technically right is
one thing, actually being able to express your opinion another and making
someone else understand yet another. In particular for the latter, you do
need some 'feeling', which is a complete non-technical skill.

Uli

 

[pek]

For this sort of thing, use 'assert':

  public class ChatExample {

    private final Connection conn; // final added

    public ChatExample() {
      // I intentionally forget to instantiate the conn

      assert conn != null;
    }

    public void connect() throws ConnectionException {
      assert conn != null;

      try {
        conn.connect();
      } catch (ConnectionExcetpion e) {
        // Delegate the exception
        throw new ConnectionException("Connection failed in Chat",e);
      }
    }

    public sendMessage(String message) throws ConnectionException {
      assert conn != null;

      try {
        conn.sendMessage(message);
      } catch (ConnectionException e) {
        // Delegate the exception
        throw new ConnectionException("Couldn't send message in
  Chat",e);
      }
    }

We assume some appropriate mechanism for invoking conn.close(), not shown here.

Now it is impossible to throw NPE.  Problem solved.

As for rethrowing the ConnectionException, that is controversial.  At some
point you should recover to correct program state instead of propagating the
exception.  Also, in real life of course one would log the ConnectionException.

Oh, and by the way, did anybody read this:

"Do not use assertions for argument checking in public methods.

Argument checking is typically part of the published specifications
(or contract) of a method, and these specifications must be obeyed
whether assertions are enabled or disabled. Another problem with using
assertions for argument checking is that erroneous arguments should
result in an appropriate runtime exception (such as
IllegalArgumentException, IndexOutOfBoundsException, or
NullPointerException). An assertion failure will not throw an
appropriate exception. "

from http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html

Uhm, so I guess

public void connect() throws ConnectionException {
assert conn != null;

try {
conn.connect();
} catch (ConnectionExcetpion e) {
// Delegate the exception
throw new ConnectionException("Connection failed in Chat",e);
}
}

this would violate what you just read because a NullPointerException
isn't thrown.

 

[pek]

Oh, and by the way, did anybody read this:

"Do not use assertions for argument checking in public methods.

Argument checking is typically part of the published specifications
(or contract) of a method, and these specifications must be obeyed
whether assertions are enabled or disabled. Another problem with using
assertions for argument checking is that erroneous arguments should
result in an appropriate runtime exception (such as
IllegalArgumentException, IndexOutOfBoundsException, or
NullPointerException). An assertion failure will not throw an
appropriate exception. "

fromhttp://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html

Uhm, so I guess



this would violate what you just read because a NullPointerException
isn't thrown.

Oops, OK, correcting my self. Your code doesn't violate that. I
went to see if you tried to assert the message parameter, which you
didn't, which means that if conn isn't null, and message is, the
conn.sendMessage(message) with throw a NPE (assuming it will use a
method of String).

So, not checking if message is null was intentionally or not? And if
you didn't check it because it was a String, if it where a type of
Message, what would you do? Would you check with assert? Would you
manually check it? Or none of the above and let a NPE be thrown?

 

[RedGrittyBrick]

To me, a program that terminates with a useful error message didn't crash.
The exception reason including the backtrace (i.e. the Java default
behaviour when an exception isn't caught) already qualifies as such.

If some application like, say, MS Word terminated whilst I was using it
and displayed "NullPointerException" and a stack trace, I'd describe it
as having crashed.

I'd be surprised if the general population of MS Word users felt any
different.

 

[Lew]

Also, by what I see, you changed your code

Yes, and explained why I did so in that post. It was to illustrate a
point about 'assert' preventing the exception in the case where the
matter is an invariant, as in your example.

from
if ( conn == null ) {
  handleIt();

} else {
  conn.connect();
}

to

assert conn != null

WHICH IS STILL CHECKING FOR NULL!

Exactly!

And that is a Good Thing!

Especially because the check disappears in production but can easily
be switched back on for debugging.

 

[Lew]

Oh, and by the way, did anybody read this:

"Do not use assertions for argument checking in public methods..... "

fromhttp://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html

Uhm, so I guess



this would violate what you just read because a NullPointerException
isn't thrown.

It does not violate what you just read, because 'conn' is not a
parameter to the public method. In this context, 'assert' was not
used for argument checking. Notice that the method, by your own
definition BTW, takes no arguments.

Look carefully. The 'assert' declares an algorithmic invariant that
should be enforced in the constructor. The AssertionError is the
programmer's clue that they didn't do that correctly.

Again, note that this is not an example of using 'assert' for argument
checking, given that the method takes no arguments.

 

[Lew]

Oops, OK, correcting my self. Your code doesn't violate that. I
went to see if you tried to assert the message parameter, which you
didn't, which means that if conn isn't null, and message is, the
conn.sendMessage(message) with throw a NPE (assuming it will use a
method of String).

WHy assume? Doesn't the Javadoc for the method tell you how it
handles null input?

So, not checking if message is null was intentionally or not? And if

I was making a point about 'assert' for the 'conn' variable. Adding a
lot of commentary about 'message' would have been off that point.
Also,l I simply assumed that sendMessage() did the right thing with
it, or you'd have checked for null yourself. I didn't want to second-
guess you.

you didn't check it because it was a String, if it where a type of
Message, what would you do? Would you check with assert? Would you
manually check it? Or none of the above and let a NPE be thrown?

That depends. Mostly if there were an exception I'd want to log it
and get the program back to sensible state. Just letting an exception
crash the program means that I can't clean up other resources, I can't
control the logging of the event, and I make an ugly experience for
the user. I much prefer to catch the exception, log it, and get back
on solid ground.

 

[pek]

WHy assume?  Doesn't the Javadoc for the method tell you how it
handles null input?

Why should it? Isn't it obvious that since it needs a String, it will
use it? Otherwise it wouldn't need the String. Why should EVERY method
that accepts any object should state that if the object is null a NPE
will be thrown? Again, isn't that obvious? If passing a null makes a
method behave differently, that is when I expect that it would javadoc
that the parameter can also be null. OR, provide an overloaded method
that doesn't have that object in its parameter. Otherwise it's common
sense.

I was making a point about 'assert' for the 'conn' variable.  Adding a Agreed.

lot of commentary about 'message' would have been off that point.

So, if the method had 5 object parameters, you would check every
single one if it is null, and then call the method. Which brings us
back from where we started: isn't it overkill?

Also,l I simply assumed that sendMessage() did the right thing with
it, or you'd have checked for null yourself.  I didn't want to second-
guess you.

So if the javadoc didn't state anywhere that by passing a null would
throw a NPE, you would assume that it would work with null?

That depends.  Mostly if there were an exception I'd want to log it
and get the program back to sensible state.  Just letting an exception
crash the program means that I can't clean up other resources, I can't
control the logging of the event, and I make an ugly experience for
the user.  I much prefer to catch the exception, log it, and get back
on solid ground.

I didn't say that you will not handle the NPE.You could catch and log
it in the main method, thus avoiding checking any null reference in
any part of your program and not crashing. Isn't this easier that
checking?

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lew schreef:
| Jack wrote:
|> How can you be so arrogant ?
|
| It isn't a question of arrogance, and I apologize for giving that
| impression.
|
| I also apologize if that hurt your feelings.

Keep up improving the world, Lew.

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIUOYLe+7xMGD3itQRAiN1AJ9h7ZmKk+NpavJOxQAL7V4unTsG2gCfQ93P
uTW8MX6yOmvlFAnckfnt/x4=
=oUWc
-----END PGP SIGNATURE-----

 

[pek]

No, it isn't.

But the job is better done by preventing null than by reacting to it.

Uhm... So, checking and logging is preventing. What is the difference
than what I said about putting NPE try catch in the main method? They
both log it and don't let your program crash.

So you have never seen bugs in production code, ever?

Of course I have

One problem is that data comes at you at run time, not test time. You have to
have a mechanism in place to deal with that data.

Agreed, I have already proposed a mechanism to deal with that.

Another problem is that you don't control how public methods are called. How
can you test a program not yet written? Are you going to vouch for all future
users of your code ahead of time?

That is why javadoc exists. But again, I wouldn't state in the javadoc
that an object must be non-null. I think that since I'm asking for it,
I will be using it, thus, if it's null, it'll throw a NPE. If my
method would work even if the object is null a would state it in the
javadoc or provide and overloaded method that doesn't have it.

That's a disconnect. I've been talking about all sorts of exceptions. But

I know, that's the problem. You are generalizing. I never said to not
check at all the parameters, just NPE.

getting a null value isn't only a bug - it can come from a user action. By
definition, user actions are never bugs. The trick is to code for the case
where a user action submits a null.

What do you mean by user actions are never bugs? If you have a bug in
your code and the testing didn't show it but a user action triggered
it, it is not the user actions fault, it's yours. You let a user
action call a method that passes a null, which shouldn't happen in the
first place, so it's a bug.

Every case is different, as I already stated.

You keep arguing to let a program crash. That is a horrible, horrible idea.

Yes, it's a horrible, horrible idea. I wonder where did I say that.
Can you please point me to the phrase that concludes this. Not
checking for NPE doesn't mean that you won't catch it. I said it more
than 10 times: I'm not against not catching a NPE at all, I'm against
checking it. If you catch a NPE from your main method, the program
WILL NOT CRASH. So stop saying things I never said.

I am arguing for catching conditions that could cause a crash, and even more
for preventing them in the first place. I say check for bad input, you say
not to bother. That means your programs will break when you get bad input,
and mine won't. My customers will be happier than yours.

You can argue all you want. I will continue to serve my customers and not
your mistaken viewpoint.

You are oversimplifing things. Not checking for NPE does not mean not
checking for any input. Of course you will. But checking for NPE isn't
a bad input, it's a bug. I can't imagine how an end-user that uses
your program will do an action that will result in calling a method
with a null parameter and not being a bug. Not checking user input !=
not checking NPE. Of course you will see if the user enter a name or
nothing! Who said otherwise?