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

Michael Brohl reassigned OFBIZ-9814:
------------------------------------

    Assignee: Michael Brohl

> [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
>            Assignee: Michael Brohl
>            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 findb...@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)

Reply via email to