You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "John Hewson (JIRA)" <ji...@apache.org> on 2014/06/12 08:37:02 UTC

[jira] [Commented] (PDFBOX-2132) Provide a pluggable exception handler to PDFStreamEngine

    [ https://issues.apache.org/jira/browse/PDFBOX-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14028873#comment-14028873 ] 

John Hewson commented on PDFBOX-2132:
-------------------------------------

I'd suggest just removing the following code from PDFStreamEngine instead:

{code}
        catch (Exception e)
        {
            LOG.warn(e, e);
        }
{code}

Because catching any exception caused by any operator is not what we should be doing - there are already specific places where we do quite broad exception catching for robustness reasons but this isn't one of them and looks like it should be removed - especially as it catches "Exception".

> Provide a pluggable exception handler to PDFStreamEngine
> --------------------------------------------------------
>
>                 Key: PDFBOX-2132
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-2132
>             Project: PDFBox
>          Issue Type: Improvement
>          Components: Rendering
>    Affects Versions: 2.0.0
>            Reporter: Petr Slaby
>         Attachments: ExceptionHandler.patch
>
>
> In our text processing and OMS application, PDFs are used as attachments to documents and rendered to target formats, among others AFP or PCL. The rendering part is implemented as a Graphics2D which gets called from PageDrawer and produces corresponding commands in the target printing language. 
> As PDF is a much richer language than AFP or PCL, there are cases when we are not able to directly implement the corresponding g2d function (e.g. partial transparency of objects in AFP as it only supports transparency masks in bitmaps). In such case, the g2d implementation throws an UnsupportedOperationException which is supposed to abort the rendering in PDFBox. We catch the exception back in our code and render the PDF as a full page bitmap using a BufferedImage instead.
> Current PDFBox trunk implementation swallows all exceptions that happen in PDFStreamEngine. For our purposes, a pluggable exception handler that can log all exceptions and re-throw UnsupportedOperationException would be perfect. A simple solution that works for me is shown in the attached patch.



--
This message was sent by Atlassian JIRA
(v6.2#6252)