Fred I enjoyed reading your analysis. I agree, PDFBox throws too many exceptions when compared to similar codebases.
Your suggestion to attempt to repair parsing errors rather than throw exceptions solves the underlying problem, presuming a repair is possible. If a repair is not possible then the user can do no better and throwing a non-recoverable IOException with a clear message such as "The PDF file is invalid" is the most that can be done. In the case of a conforming parser, no recovery is permitted and so in that case throwing a non-recoverable exception is required. Your proposed approach seems ideal: it avoids the need for any non-trivial exception handling on the part of the user, nor does it generate exceptions from common and auto-resolvable errors. Great, thanks. -- John > On 16 Feb 2014, at 14:36, Fred Hansen <[email protected]> wrote: > > I've converted the attachment to a web page: > http://physpics.com/Java/Notes/ExceptionHandling.php > > > > >> ________________________________ >> From: Maruan Sahyoun <[email protected]> >> To: "[email protected]" <[email protected]> >> Sent: Sunday, February 16, 2014 3:36 AM >> Subject: Re: [DISCUSS] PDFBox and Exception handling >> >> >> Hi Fred, >> >> unfortunately the attachment didn't make it through due to restrictions of >> the mailing list - could you make it available somewhere on a public site? >> >> BR >> >> Maruan Sahyoun >> >> >>> Am 16.02.2014 um 01:04 schrieb Fred Hansen <[email protected]>: >>> >>> >>> Just in case you're not tired of exceptions, I've written the attached. It >>> concludes that the right-thing-to-do is to examine individually each throw >>> statement. >>
