Best practice for handling null strings from database (in Java)

Question

In my database application I sometimes have to deal with null strings in the database. In most cases this is fine, but when it comes do displaying data in a form the Swing components - using JTextField for example - cannot handle null strings. (.setText(null) fails)

(EDIT: I just noticed that JTextField actually accepts a null string, but the question remains for all other cases where unexpected null values can lead to problems.)

The null values have no special meaning, they can (must) be treated as empty strings.

What is the best practice to deal with this problem? Unfortunatly I cannot change the database.

• Checking every value if it is null before calling setText()?
• Adding a try-catch handler to every setText() call?
• Introducing a static method which filters all null strings?
• Replace all null values to empty strings immediatly after reading from the database?
• ... [your suggestions]

Answer 1

If you can, add a default value - empty string - for a field in DB .

Answer 2

If you are using any ORM tool or somehow you map your DB fields to Java bean you can allways have:

public void setFoo(String str) {
  this.foo = str != null ? str : "";
}

Answer 3

From a SQL angle try:

select ISNULL(column_name,'') from ...

Answer 4

You could extend or wrap JTextField and overwrite the setText() method to replace NULL with an empty String.

Answer 5

As Ruben said I would extend the JTextField to overwrite the setText() method and replace NULL with the empty string.

However I would also overwrite the getText() method to overwrite empty string with NULL so that when you are saving back into the database you do not overwrite a null value in there with the empty string.

Answer 6

Use Beans Binding API to bind values from your entity objects to your SWING Widgets. Beanins Binding will transparently handle null values and will not replace the null with an empty string.

Answer 7

I think all your answers are reasonable, but since you tagged this "best practices", I'd like to remind you of the null object design pattern. Wherever it seems worth the effort, for whatever class need the protection, write special instantiation code for a "null" object of that class. The idea is this "null" object is real, and can behave appropriately no matter what you ask it to do. Your null "String" object could provide whatever you want as it's value.

This pattern also means you can get rid of lots of null checks, and the code is more robust. It does use up a bit of CPU sending messages to nulls and having them do nothing, so it is less desirable when a large percentage of objects are expected to be null.