Am 10.02.2018 um 07:25 schrieb Maruan Sahyoun:

Am 09.02.2018 um 23:06 schrieb Mark Tanner <>:

hey all

Java has quite strict enforcement of exception handling. I.e. if a method can 
throw an exception then the calling method must handle it, and you get plenty 
of compiler warnings telling you such.

We can avoid NPE's by avoiding returning null from methods completely, and 
throwing an exception instead.
I'd think that throwing an exception if something required is missing is OK. 
Throwing an exception for retrieving an optional value is not. And that's the 
case we are talking about. And it's for the high level PD model within PDFbox - 
the API most of our users are using and should anyway.

Now for an optional value which may or may not exist - like an drop down field 
options - shall we return null or an empty array(collection?

Same as I said last time... I'm always wondering whether there could be a case where we want to know whether the object is missing, or when we write back the object and a PDF would then have an empty object instead of nothing at all.

It also depends whether the behavior is different whether an item is empty vs an item is missing. Adobe behaves differently whether the color of a link annotation is missing (will draw a black line) or is empty (will draw nothing).



This will also allow us to customize the message of the exception and let the 
user know why they aren't getting their expected results.

Any thoughts?

Mark Tanner
From: Tilman Hausherr []
Sent: 09 February 2018 18:50
Subject: Re: [DISCUSS] return values for functions

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:

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

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

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

Reply via email to