Julian Leichert created OFBIZ-9814:
--------------------------------------
Summary: [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
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)
