Am 09.02.2018 um 19:20 schrieb Andreas Lehmkuehler:
Am 17.01.2018 um 18:41 schrieb Maruan Sahyoun:

many of our methods return null in case an entry can not be found potentially causing NPEs. For 3.0 what about starting to change that so we return the expected object in the PDModel although I understand that this might mean that for some time some methods might return null where others might return the expected object.

E.g. in PDAnnotationTextMarkup.getQuadPoints() in the unlikely case that there is no sufficient entry instead of return null we could return an empty float[].

Wouldn't expect that we start looking for such cases but doing it as we touch methods.

I never thought about that. What exactly is the advantage of this strategy? In the end I'm doing "is empty checks" instead of "is not null checks".


It's a programming style that is expected to avoid NPEs, Sonar mentions it at some places. The advantage is that you could run a loop on the result without null checking.


To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to