[
https://issues.apache.org/jira/browse/PDFBOX-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14498611#comment-14498611
]
ASF subversion and git services commented on PDFBOX-2566:
---------------------------------------------------------
Commit 1674143 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1674143 ]
PDFBOX-2566: delete wrong operand count on more operators
> Remove logging from operator classes
> ------------------------------------
>
> Key: PDFBOX-2566
> URL: https://issues.apache.org/jira/browse/PDFBOX-2566
> Project: PDFBox
> Issue Type: Improvement
> Components: PDModel
> Affects Versions: 2.0.0
> Reporter: John Hewson
> Assignee: John Hewson
> Priority: Minor
> Fix For: 2.0.0
>
>
> I've been trying to get better control over the logging that occurs in the
> operator classes, but it's not easy to do so. Ideally all logging could pass
> through PDFStreamEngine so that subclasses can more easily filter what they
> want. By using exceptions instead of logging for error cases, we allow more
> fine-grained management of exceptions. For example, in my own code I wish for
> a missing XObject to be a terminal failure, but it currently just results in
> a log message, and I have to implement a custom DrawObject operator and copy
> & paste over most of the code in order to catch this exception rather than
> logging it.
> I'm therefore going to move what little logging there is in the Operator
> classes over to PDFStreamEngine, and to throw custom exceptions (e.g.
> MissingResourceException) rather than writing silently to the log. The
> default implementation of processOperator in PDFStreamEngine will then catch
> these custom exceptions and simply write them to the log - keeping the
> current PDFBox behaviour unchanged. Only now consumers of PDFStreamEngine can
> override processOperator and do their own exception handling, e.g. I can
> choose to propagate MissingResourceException exception instead of logging it.
> This might be useful for Preflight too, as it often wants to throw errors
> where we would otherwise skip the offending object and just keep processing.
> Also it probably means that there will no longer be a need for to Preflight
> implement its own operators in those cases where it was done just to get
> stricter error handing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
