Using JavaScript for business rules should always include a mechanism for handling exception errors. If not coded correctly, additional errors can be generated. The following recommendations should be followed to produce accurate errors that can be addressed.
When using try-catch for handing exception errors, errors are logged to the step.0.log. While this is effective for documenting what happened, it does not give the user a chance to address the error from STEP, and the STEP framework is not informed of the error and therefore cannot handle other scenarios like Optimistic Lock Exceptions. To avoid this, it is important to include a 'throw' when catching errors.
|
Wrong |
Right |
|---|---|
try {//Some code } catch(e) {logger.info(e); } |
try {//Some code } catch (e) {logger.info(e); throw(e);} |
Although not recommended setup, if you use try-catch for handling expected exceptions, it is important that your catch logic only ignores the specific intended exceptions, and that all other exceptions are rethrown. Again, this allows the framework to process unexpected exceptions correctly and avoids potential data inconsistency.
The code snippet below shows how it is possible to handle expected and unexpected exceptions differently. Notice the necessary Rhino specific 'e.javaException' notation.
try {currentObject.createReference(targetProduct, accRefType.getID());
} catch (e) { if (e.javaException instanceof com.stibo.core.domain.reference.TargetAlreadyReferencedException) { logger.warning("Reference already exists"); } else {throw (e);
}
}
2017, Stibo Systems