ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Leichert (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OFBIZ-9814) [FB] Package org.apache.ofbiz.content.output
Date Thu, 05 Oct 2017 15:42:00 GMT

     [ https://issues.apache.org/jira/browse/OFBIZ-9814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Julian Leichert updated OFBIZ-9814:
-----------------------------------
    Attachment: OFBIZ-9814_org.apache.ofbiz.content.output_bugfixes.patch

class OutputServices
 - line 188, 257 : Changed catch(Exception e) to multicatch for better visibility and Exceptionhandling

> [FB] Package org.apache.ofbiz.content.output
> --------------------------------------------
>
>                 Key: OFBIZ-9814
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-9814
>             Project: OFBiz
>          Issue Type: Sub-task
>          Components: content
>    Affects Versions: Trunk
>            Reporter: Julian Leichert
>            Priority: Minor
>         Attachments: OFBIZ-9814_org.apache.ofbiz.content.output_bugfixes.patch
>
>
> OutputServices.java:187, REC_CATCH_EXCEPTION
> - REC: Exception is caught when Exception is not thrown in org.apache.ofbiz.content.output.OutputServices.sendPrintFromScreen(DispatchContext,
Map)
> This method uses a try-catch block that catches Exception objects, but Exception is not
thrown within the try block, and RuntimeException is not explicitly caught. It is a common
bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching
a number of types of exception each of whose catch blocks is identical, but this construct
also accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that are thrown,
or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime
Exceptions, as shown below:
>   try {
>     ...
>   } catch (RuntimeException e) {
>     throw e;
>   } catch (Exception e) {
>     ... deal with all non-runtime exceptions ...
>   }
> OutputServices.java:251, OBL_UNSATISFIED_OBLIGATION_EXCEPTION_EDGE
> - OBL: org.apache.ofbiz.content.output.OutputServices.createFileFromScreen(DispatchContext,
Map) may fail to clean up java.io.OutputStream on checked exception
> This method may fail to clean up (close, dispose of) a stream, database object, or other
resource requiring an explicit cleanup operation.
> In general, if a method opens a stream or other resource, the method should use a try/finally
block to ensure that the stream or resource is cleaned up before the method returns.
> This bug pattern is essentially the same as the OS_OPEN_STREAM and ODR_OPEN_DATABASE_RESOURCE
bug patterns, but is based on a different (and hopefully better) static analysis technique.
We are interested is getting feedback about the usefulness of this bug pattern. To send feedback,
either:
>     send email to findbugs@cs.umd.edu
>     file a bug report: http://findbugs.sourceforge.net/reportingBugs.html
> In particular, the false-positive suppression heuristics for this bug pattern have not
been extensively tuned, so reports about false positives are helpful to us.
> See Weimer and Necula, Finding and Preventing Run-Time Error Handling Mistakes, for a
description of the analysis technique.
> OutputServices.java:251, OS_OPEN_STREAM_EXCEPTION_PATH
> - OS: org.apache.ofbiz.content.output.OutputServices.createFileFromScreen(DispatchContext,
Map) may fail to close stream on exception
> The method creates an IO stream object, does not assign it to any fields, pass it to
other methods, or return it, and does not appear to close it on all possible exception paths
out of the method.  This may result in a file descriptor leak.  It is generally a good idea
to use a finally block to ensure that streams are closed.
> OutputServices.java:255, REC_CATCH_EXCEPTION
> - REC: Exception is caught when Exception is not thrown in org.apache.ofbiz.content.output.OutputServices.createFileFromScreen(DispatchContext,
Map)
> This method uses a try-catch block that catches Exception objects, but Exception is not
thrown within the try block, and RuntimeException is not explicitly caught. It is a common
bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching
a number of types of exception each of whose catch blocks is identical, but this construct
also accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that are thrown,
or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime
Exceptions, as shown below:
>   try {
>     ...
>   } catch (RuntimeException e) {
>     throw e;
>   } catch (Exception e) {
>     ... deal with all non-runtime exceptions ...
>   }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message