[
https://issues.apache.org/jira/browse/PDFBOX-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Hewson updated PDFBOX-2566:
--------------------------------
Description:
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 rather than
writing silently to the log, e.g. MissingResourceException for my missing
XObject. 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. Only now consumers of PDFStreamEngine can
override processOperator and do their own exception handling, e.g. I can choose
to propagate the missing XObject 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.
was:
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 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. Only now consumers of
PDFStreamEngine can override processOperator and do their own exception
handling, e.g. I can choose to propagate the missing XObject 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.
> 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
> 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 rather than
> writing silently to the log, e.g. MissingResourceException for my missing
> XObject. 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. Only now consumers of PDFStreamEngine
> can override processOperator and do their own exception handling, e.g. I can
> choose to propagate the missing XObject 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
