Null pointer when accessing storage???

[S. Dale Morrey]

I'm seeing a null pointer when accessing storage even though to the best of my knowledge it SHOULD NOT be null by this point.

Here is the code...

/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */
package com.coloradocash;

import com.codename1.components.MultiButton;
import com.codename1.io.Storage;
import com.codename1.ui.Component;
import com.codename1.ui.Form;
import userclasses.StateMachine;

public class SettingsManager {
    private static Storage storage = Storage.getInstance();
   
    public static void stateChanged(MultiButton c){
        String name = c.getName();
        Boolean state = c.isSelected();
        storage.writeObject(name, state);
    }
   
    public static void restoreSettings(Form form){
        if(storage == null){
           
            storage = Storage.getInstance();
            System.out.println("Storage was not initialized!  Must wait!");
            Thread.yield();
            restoreSettings(form);
            return;
           
        }else{
            int count = form.getComponentCount();
            for(int i = 0; i < count; i++){
                Component c = form.getComponentAt(i);
                String name = c.getName();
                if(storage.exists(name)){
                    if(c.getClass().equals("MultiButton")){
                        MultiButton button = (MultiButton) c;
                        button.setSelected((Boolean)storage.readObject(name));
                    }
                }
            }
        }
    }
}



Here is a copy of the stack trace...
java.lang.NullPointerException
    at java.io.File.<init>(File.java:334)
    at com.codename1.impl.javase.JavaSEPort.storageFileExists(JavaSEPort.java:4066)
    at com.codename1.io.Storage.exists(Storage.java:147)
    at com.coloradocash.SettingsManager.restoreSettings(SettingsManager.java:40)

I'm seeing the null pointer exception on this line...
40 if(storage.exists(name))

The purpose of the SettingsManager is to preserve the state of the SettingsForm I created so that users could turn on or off features of the app.  Everything on the form is just MultiButtons, there isn't a container or anything.

However if storage is null it shouldn't even get to the point where it's looking to see if the component has a setting saved.
So I just don't get it, what the heck am I doing wrong here?

[S. Dale Morrey]

Ok I was able to solve this but I don't think the way it's behaving is what it should be doing.

On line 40 I wasn't checking to see if name was null or empty.  My assumption from the javadoc was that if it doesn't find anything in storage with "name" then it would return false.
Evidently if you hand it a null value or empty string it pukes and throws that null pointer exception.
I would expect it to simply return false like any other value that isn't present.

Is this expected behaviour or should this be filed as a bug report?

[Shai Almog]

Our assumption is that if you pass it null you have a bug and we generally prefer to fail fast rather than hide that bug. In your particular case it didn't help but imagine a case where you data got corrupted and you didn't check against that.

[S. Dale Morrey]

I can't imagine a case where it would be better for invalid data to throw an unhandled and undeclared exception than to have it simply return false.  Something there either exists or not, right?  Corrupted data is unlikely to produce a null, it's more likely to produce garbage. in which case the code would correctly return false.  However in this case, my user would have had a screen popup (completely unbeknownst to me), giving them a confusing and basically indecipherable error.

Isn't it best practice that if you know in advance that there is a use case where an exception may be thrown, that the exception be declared so it can be trapped and dealt with at development time?

Thanks btw, awesome toolkit, these little gotchas are driving me nuts though :)

[Shai Almog]

Thanks.
Normally you should assume null will fail. This is true for Swing and most Java frameworks, that is why null pointer is a runtime exception declaring it will be too widespread.
If we would want null to work with all code we will need to add if null to all our methods which isn't much but it ads up.