> 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
