[
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 [email protected]
> 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)
