NullPointerException occurred randomly

Hello,

I got NullPointerException randomly from the following button click listener on production environment. This click listener is for cancel button on a modal window.
Everything is supposed to exist while the code is being executed. I run my application from eclipse, and there is no problem at all.
Is there anyone could possibly explain this?

PS. Vaadin 6.8.2, Tomcat 7.0.19, JRockit JVM


	private class CancelJobClickListener implements ClickListener
	{
		private static final long serialVersionUID = 7425745614079625369L;

		@Override
		public void buttonClick(ClickEvent event) 
		{
			event.getButton().getApplication().getMainWindow().removeWindow(event.getButton().getWindow());
		}
		
	}

In production you say? I have a far fetched guess but not sure if it is even possible to happen in Vaadin or not. So I guess that there are end-users using the software on the production server. If some of these end-users are something like my parents on a computer, they will be double-clicking on every button and link. They haven’t really grasped the concept of when a single click is enough and when it requires double-clicks. I think this issue is quite common with users of an older generation. If some user happens to double-click on the button before the first click server roundtrip has returned, it may be that a second click is fired to the server. With the assumption that this button is inside the subwindow, the first click removes the window with it, which means that the second run of the code will return null at event.getButton().getApplication() as the component is not attached anymore.

As I said, this is far fetched and it may be possible that the Vaadin already handles stuff like this, but it is worth the shot. Anyhow, even if it is or is not the case, my suggestion is the same. Break up the call into multiple rows and do null-checks. With that you’ll at least get the info which row is it that throws null. I’d bet this works:

private class CancelJobClickListener implements ClickListener {
  private static final long serialVersionUID = 7425745614079625369L;
  @Override
  public void buttonClick(ClickEvent event) {
    Button button = event.getButton();
    Application application = button.getApplication();
    if(application != null){
      Window subWindow = event.getButton().getWindow();
      application.getMainWindow().removeWindow(subWindow);
  }       
}

It might be a bit longer, but in my opinion, it is as well more readable.

Jens,

That’s a good guess. I 've followed your suggestion and ‘reinforced’ one of the cancel button’s logic. Will report back if this still happens. Thanks.

Please take a look at the
Button.setDisableOnClick()
method - it is designed exactly for situations like this. However, it seems to me that the framework itself should do checks to only fire UI event for components that are actually attached to the application. This might be worth a ticket.

I think Vaadin handles the checking if a component is in the application or not early, but my guess is that this is a special case because it is in a subwindow. The subwindow is removed, but the component is still in that removed window. It depends on if the check goes only to the closest window, or all the way up to the application.