ListEditor.class - put a try {} catch {} around the flush() { list.flush() }

73 views
Skip to first unread message

Brandon Donnelson

unread,
May 16, 2012, 8:31:17 PM5/16/12
to google-we...@googlegroups.com
How about put a try catch around the list.flush() for tracking down the offending null list. 

ListEditor.class {
  //...
  public void flush() {
    list.flush(); // <<<< try catch this for easier debugging
  }
  //...
}

Thoughts?

Brandon Donnelson

Thomas Broyer

unread,
May 17, 2012, 6:19:26 AM5/17/12
to google-we...@googlegroups.com


On Thursday, May 17, 2012 2:31:17 AM UTC+2, Brandon Donnelson wrote:
How about put a try catch around the list.flush() for tracking down the offending null list. 

ListEditor.class {
  //...
  public void flush() {
    list.flush(); // <<<< try catch this for easier debugging
  }
  //...
}

Thoughts?

What would the "catch" block do?

Wouldn't the correct fix rather be: if (list != null) { list.flush(); }

Brandon Donnelson

unread,
May 17, 2012, 10:47:10 AM5/17/12
to google-we...@googlegroups.com
Thats a good point and as soon as I posted that I wondered that my self. 

The first thing I'd like to do is pause on it and see which of my list editors has a null list because the list editor wants an empty or greater list. But pausing on every list is tiresome and would rather pause on an exception. Better yet, the next thing I was wondering is either add an assertion to the editor saying the list can't be null or add a better trace for the list NPE, saying something like PeopleListEditor can't be null. 

The way I find them now is make sure any lists on the server side when null send an empty. 

Have a good day,
Brandon Donnelson


--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/j72sBQj23r8J.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

Thomas Broyer

unread,
May 17, 2012, 11:26:37 AM5/17/12
to google-we...@googlegroups.com


On Thursday, May 17, 2012 4:47:10 PM UTC+2, Brandon Donnelson wrote:
Thats a good point and as soon as I posted that I wondered that my self. 

The first thing I'd like to do is pause on it and see which of my list editors has a null list because the list editor wants an empty or greater list.

That's not quite true (as you'll see setValue has specific code for null values). It's just that it'll only work for display (i.e. as long as you don't call flush()).
 
But pausing on every list is tiresome and would rather pause on an exception.

Did you know you can set breakpoints on exceptions? ;-)

Brandon Donnelson

unread,
May 17, 2012, 2:47:22 PM5/17/12
to google-we...@googlegroups.com
True that would fix the flush. But I'm wondering if this isn't a symptom of an earlier problem. I'm thinking if the list is null on instantiation the list backing doesn't get setup properly. So the question I would have is if I add an item, will the list no longer be null and it seems to me that it will still be null. So I think to fix the problem might be to instantiate the list differently as well. 

Have a good day,
Brandon Donnelson


On Thu, May 17, 2012 at 3:19 AM, Thomas Broyer <t.br...@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

Brandon Donnelson

unread,
May 17, 2012, 2:49:12 PM5/17/12
to google-we...@googlegroups.com
It seems, the listeditor backing only get setup properly if the list is empty, when it's null the whole process for list editor breaks down. The backing list won't even get set when its null, and adding an item when it starts out null I think doesn't work. 

Thomas Broyer

unread,
May 17, 2012, 4:40:21 PM5/17/12
to google-we...@googlegroups.com


On Thursday, May 17, 2012 8:47:22 PM UTC+2, Brandon Donnelson wrote:
True that would fix the flush. But I'm wondering if this isn't a symptom of an earlier problem. I'm thinking if the list is null on instantiation the list backing doesn't get setup properly. So the question I would have is if I add an item, will the list no longer be null and it seems to me that it will still be null. So I think to fix the problem might be to instantiate the list differently as well.

You won't be able to add an item, as ListEditor#getList() will return 'null' if 'null' was passed to setValue().

Originally, when asked about 'null', BobV said you should use an OptionalFieldEditor in between the parent editor and the ListEditor (and then months later he added the 'null' handling in ListEditor#setValue). In this case, I think the OptionalFieldEditor is the way to go: if you want to "add a value to a 'null' list", then first make it "non-null" by calling the OptionalFieldEditor's setValue with an empty list, then add an element to ListEditor#getList() (which will then be non-null). I suppose, as an "optimization", you could also directly set a non-empty/populated list to the OptionalFieldEditor.

Brandon Donnelson

unread,
May 17, 2012, 5:13:48 PM5/17/12
to google-we...@googlegroups.com
If Null is As Designed for the ListEditor, I suggest using an assertion to tell the user. I don't mind sending the List Editor an empty list, its when I forget to do code for that, that I try finding it.  I appreciate the info about the other options. Thanks for looking at this too. 

I'll have to setup breakpoints on exceptions. Thanks for the tip. 

Have a good day,
Brandon Donnelson


--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

Thomas Broyer

unread,
May 17, 2012, 9:22:23 PM5/17/12
to google-we...@googlegroups.com


On Thursday, May 17, 2012 11:13:48 PM UTC+2, Brandon Donnelson wrote:
If Null is As Designed for the ListEditor, I suggest using an assertion to tell the user. I don't mind sending the List Editor an empty list, its when I forget to do code for that, that I try finding it.  I appreciate the info about the other options. Thanks for looking at this too. 

I'll have to setup breakpoints on exceptions. Thanks for the tip.

FYI, fix proposed and discussed here (as part of another fix): http://gwt-code-reviews.appspot.com/1664803/ 

Brandon Donnelson

unread,
May 17, 2012, 9:41:23 PM5/17/12
to google-we...@googlegroups.com
Awesome! Thanks :)

Have a good day,
Brandon Donnelson


--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
Reply all
Reply to author
Forward
0 new messages