> Am 09.02.2018 um 19:20 schrieb Andreas Lehmkuehler <andr...@lehmi.de>:
> 
> Am 17.01.2018 um 18:41 schrieb Maruan Sahyoun:
>> Hi,
>> 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.
>> WDYT?
> 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 lessens the risk of NPE in our code and in the users code
# it avoids duplicate checks e.g. if myList != null && myList.contains
# it eases the usage of for each if we ensure that there is an empty collection 
or array returned

…

Maruan

> 
> Andreas
> 
>> BR
>> Maruan
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
>> For additional commands, e-mail: dev-h...@pdfbox.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
> For additional commands, e-mail: dev-h...@pdfbox.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Reply via email to