we are currently building our first solution with the OpenSpan technology and we are working on putting together an error handling strategy. We've seen from a previous PEGA built solution that it was intentionally suppressing unhandled errors (using a method from the Test Harness) when on the PROD configuration. We were wondering what were the motivations of doing this vs having the solution display these unhandled errors to the user or having a try/catch block around the whole thing and handling those there. Any insight on the error handling best practices?
I would argue that the average user does not care about the errors that happen in scenarios that aren't handled. They can be distracting and disconcerting for a user trying to get his/her work done and an automation error does not necessarily mean that the automation has stopped working. It might cause a lack of confidence by the user to use the solution as well in some cases. Displaying a more user friendly message is completely understandable strategy though but generally the errors produced make no sense to someone who isn't familiar with the product.
SuppressErrors is simply a safe-guard for anything you don't handle. Try-Catch's are the recommended best practices to surround automations that could fail and including descriptive messages logged out to the log.
Posted: 4 years ago
Posted: 20 Oct 2017 15:37 EDT
Jeff Badger (jeffbadger)
Principal Product Manager, Robotics
Unless I'm mistaken, Suppress Errors basically ignores exceptions and carries on with the execution. We therefore need to make sure those are catched in a Try..Catch or it might lead to the automation reaching completion in a broken kind of way. Is that a valid statement?