If for some reason null is returned in the SerializableFunction sended as a parameter in the constructor of a ComponentRenderer, like in the following example:
Grid<String> testGrid = new Grid<>();
testGrid.addColumn(new ComponentRenderer<>(item-> {
return null;
}));
testGrid.setItems(Arrays.asList("one","two","three"));
Then the following exception is produced:
Caused by: java.lang.NullPointerException
at com.vaadin.flow.data.provider.AbstractComponentDataGenerator.registerRenderedComponent(AbstractComponentDataGenerator.java:110)
at com.vaadin.flow.data.provider.ComponentDataGenerator.generateData(ComponentDataGenerator.java:80)
at com.vaadin.flow.data.provider.CompositeDataGenerator.lambda$generateData$0(CompositeDataGenerator.java:47)
at java.lang.Iterable.forEach(Iterable.java:75)
at com.vaadin.flow.data.provider.CompositeDataGenerator.generateData(CompositeDataGenerator.java:47)
at com.vaadin.flow.data.provider.DataCommunicator.generateJson(DataCommunicator.java:644)
It can be avoided by just returning an empty label, but it could be confusing at times as it doesn't specify which column is generating the issue.
Hi @mlopezFC ,
Thanks for reporting this. It looks like a bug, but after further investigation, it might be also an enhancement.
Is there a good use case that you want to return null in the componentRenderer? if yes, we might need to provide this kind of support somehow. Otherwise, the fix can be thrown a more meaningful exception.
I will mark it as a bug firstly, if you have more concerns, leave your comments here.
Suppose you have to decide which component to render based on certain conditions. And with a specific one, you need to show just an empty space. Returning null would be a good and clean way of telling "I don't want anything here", if not then the developer will need to decide if return an empty span, div or label.
Allowing return null; saves you from typing a couple of characters compared to return new Span();. At the same time, it makes the code slightly less explicit about what happens and it will remove the chance of discovering genuine bugs in the code.
Good point. The risk of a genuine bug going through unnoticed outweighs the benefit of treating null as just an empty span.
However, I think it would still be helpful to know which of the columns in the grid is throwing that exception. Would it be possible to identify it using the column's key or id?
Making the error message clearer would be a very good improvement.
Most helpful comment
Making the error message clearer would be a very good improvement.