Hi John, currently pdfbox mostly throws IOExceptions where the user of the lib is not able to do something about it.
Some of these exceptions could occur because a file was not found etc. So that’s ok. Others might occur because objects are not at a certain position. There are workarounds for some of these in pdfbox e.g. if %%EOF ist not the last entry in a PDF. Thus users are dependent on us putting in the workarounds to handle such situations. Now let’s assume there is a situation where an object is not at a certain location, or a specific string is missing …. what if we throw an exception where one could register a handler. We pass some kind of context e.g. lexer, file position, token …. and the user can handle the exception and „enrich“ the content or pass the correct information. The exception is than resolved and the process can continue. In addition to that we are able to extend from a strictly conformant parsing to a relaxed parsing by using the same mechanism thus having the workarounds not in the ‚core‘ parser. BR Maruan Sahyoun Am 13.02.2014 um 09:44 schrieb John Hewson <j...@jahewson.com>: > I'm not sure in understand what you mean, the Camel examples are very complex > indeed. A quick concrete example of what you're after would help greatly. > > -- John > >> On 13 Feb 2014, at 00:20, Maruan Sahyoun <sahy...@fileaffairs.de> wrote: >> >> Hi, >> >> what do you think of having an exception handling in pdfbox where people >> could define their own handlers. Something similar to >> >> https://camel.apache.org/exception-clause.html >> >> The benefit would be that we could pass the context e.g. during PDF parsing >> and the handler could return something which is than taken as the input. In >> addition to that maybe we can think about having some additional types of >> exceptions instead of mostly IOException to support that. >> >> BR >> Maruan Sahyoun >>
