Minor Description
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.