[
https://issues.apache.org/jira/browse/OFBIZ-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl reassigned OFBIZ-9732:
------------------------------------
Assignee: Michael Brohl
> [FB] Package org.apache.ofbiz.order.test
> ----------------------------------------
>
> Key: OFBIZ-9732
> URL: https://issues.apache.org/jira/browse/OFBIZ-9732
> Project: OFBiz
> Issue Type: Sub-task
> Components: order
> Affects Versions: Trunk
> Reporter: Julian Leichert
> Assignee: Michael Brohl
> Priority: Minor
> Attachments: OFBIZ-9732_org.apache.ofbiz.order.test_bugfixes.patch
>
>
> FinAccountTest.java:36, VA_FORMAT_STRING_USES_NEWLINE
> - FS: Format string should use %n rather than \n in
> org.apache.ofbiz.order.test.FinAccountTest.testCreateFinAccountBasic()
> This format string include a newline character (\n). In format strings, it is
> generally preferable better to use %n, which will produce the
> platform-specific line separator.
> FinAccountTest.java:47, DM_CONVERT_CAS
> - Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in
> org.apache.ofbiz.order.test.FinAccountTest.testCreateFinAccountBasic()
> A String is being converted to upper or lowercase, using the platform's
> default encoding. This may result in improper conversions when used with
> international characters. Use the
> String.toUpperCase( Locale l )
> String.toLowerCase( Locale l )
> versions instead.
> OrderTestServices.java:140, REC_CATCH_EXCEPTION
> - REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.order.test.OrderTestServices.createTestSalesOrderSingle(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 ...
> }
> SalesOrderTest.java:75, DMI_BIGDECIMAL_CONSTRUCTED_FROM_DOUBLE
> - DMI: BigDecimal constructed from 4.7 in
> org.apache.ofbiz.order.test.SalesOrderTest.testCreateSalesOrder()
> This code creates a BigDecimal from a double value that doesn't translate
> well to a decimal number. For example, one might assume that writing new
> BigDecimal(0.1) in Java creates a BigDecimal which is exactly equal to 0.1
> (an unscaled value of 1, with a scale of 1), but it is actually equal to
> 0.1000000000000000055511151231257827021181583404541015625. You probably want
> to use the BigDecimal.valueOf(double d) method, which uses the String
> representation of the double to create the BigDecimal (e.g.,
> BigDecimal.valueOf(0.1) gives 0.1).
> SalesOrderTest.java:80, DMI_BIGDECIMAL_CONSTRUCTED_FROM_DOUBLE
> - DMI: BigDecimal constructed from 1.824 in
> org.apache.ofbiz.order.test.SalesOrderTest.testCreateSalesOrder()
> This code creates a BigDecimal from a double value that doesn't translate
> well to a decimal number. For example, one might assume that writing new
> BigDecimal(0.1) in Java creates a BigDecimal which is exactly equal to 0.1
> (an unscaled value of 1, with a scale of 1), but it is actually equal to
> 0.1000000000000000055511151231257827021181583404541015625. You probably want
> to use the BigDecimal.valueOf(double d) method, which uses the String
> representation of the double to create the BigDecimal (e.g.,
> BigDecimal.valueOf(0.1) gives 0.1).
> SalesOrderTest.java:84, DMI_BIGDECIMAL_CONSTRUCTED_FROM_DOUBLE
> - DMI: BigDecimal constructed from 0.1 in
> org.apache.ofbiz.order.test.SalesOrderTest.testCreateSalesOrder()
> This code creates a BigDecimal from a double value that doesn't translate
> well to a decimal number. For example, one might assume that writing new
> BigDecimal(0.1) in Java creates a BigDecimal which is exactly equal to 0.1
> (an unscaled value of 1, with a scale of 1), but it is actually equal to
> 0.1000000000000000055511151231257827021181583404541015625. You probably want
> to use the BigDecimal.valueOf(double d) method, which uses the String
> representation of the double to create the BigDecimal (e.g.,
> BigDecimal.valueOf(0.1) gives 0.1).
> SalesOrderTest.java:89, DMI_BIGDECIMAL_CONSTRUCTED_FROM_DOUBLE
> - DMI: BigDecimal constructed from 0.039 in
> org.apache.ofbiz.order.test.SalesOrderTest.testCreateSalesOrder()
> This code creates a BigDecimal from a double value that doesn't translate
> well to a decimal number. For example, one might assume that writing new
> BigDecimal(0.1) in Java creates a BigDecimal which is exactly equal to 0.1
> (an unscaled value of 1, with a scale of 1), but it is actually equal to
> 0.1000000000000000055511151231257827021181583404541015625. You probably want
> to use the BigDecimal.valueOf(double d) method, which uses the String
> representation of the double to create the BigDecimal (e.g.,
> BigDecimal.valueOf(0.1) gives 0.1).
> SalesOrderTest.java:98, DMI_BIGDECIMAL_CONSTRUCTED_FROM_DOUBLE
> - DMI: BigDecimal constructed from 0.384 in
> org.apache.ofbiz.order.test.SalesOrderTest.testCreateSalesOrder()
> This code creates a BigDecimal from a double value that doesn't translate
> well to a decimal number. For example, one might assume that writing new
> BigDecimal(0.1) in Java creates a BigDecimal which is exactly equal to 0.1
> (an unscaled value of 1, with a scale of 1), but it is actually equal to
> 0.1000000000000000055511151231257827021181583404541015625. You probably want
> to use the BigDecimal.valueOf(double d) method, which uses the String
> representation of the double to create the BigDecimal (e.g.,
> BigDecimal.valueOf(0.1) gives 0.1).
> SalesOrderTest.java:105, DMI_BIGDECIMAL_CONSTRUCTED_FROM_DOUBLE
> - DMI: BigDecimal constructed from -3.84 in
> org.apache.ofbiz.order.test.SalesOrderTest.testCreateSalesOrder()
> This code creates a BigDecimal from a double value that doesn't translate
> well to a decimal number. For example, one might assume that writing new
> BigDecimal(0.1) in Java creates a BigDecimal which is exactly equal to 0.1
> (an unscaled value of 1, with a scale of 1), but it is actually equal to
> 0.1000000000000000055511151231257827021181583404541015625. You probably want
> to use the BigDecimal.valueOf(double d) method, which uses the String
> representation of the double to create the BigDecimal (e.g.,
> BigDecimal.valueOf(0.1) gives 0.1).
> SalesOrderTest.java:134, UC_USELESS_OBJECT
> - Useless object created
> Our analysis shows that this object is useless. It's created and modified,
> but its value never go outside of the method or produce any side-effect.
> Either there is a mistake and object was intended to be used or it can be
> removed.
> This analysis rarely produces false-positives. Common false-positive cases
> include:
> - This object used to implicitly throw some obscure exception.
> - This object used as a stub to generalize the code.
> - This object used to hold strong references to weak/soft-referenced objects.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
