francois-normandin
commented
3 years ago A commit has been made to support configurable error handling shutdown behavior. [Feature: 74] Addition of an inheritable "Error Handling Behavior" attribute to manage the way the SMO reacts on an unhandled error.
Still open question: what is the default behavior... shutdown or not?
The SMO base process method listens to callbacks for handling messages from dependencies, such as:
The question that comes to mind is "what is the default behavior om Unhandled Errors? There is no current behavior associated with unhandled error at the framework base level since there were no errors possible until this new release.
Should the default behavior be like Actor Framework and to stop the process (and its hierarchy) on any unhandled error? It seems like the good choice from a system perspective, but this means that any application built with 1.3.0 that does not clear unhandled errors would potentially see its behavior change as a result.
If the risk analysis is not predomidantly in favor of self-termination on unhandled errors, the following snippet preserves current behavior:
However, all templates currently include their flag set to true (self-termination), which might indicate that a prudent user would either make the conscious choice to set the flag to false, or would already be overwriting the "Handle Error,vi" method in a way that satisfies their needs:
Therefore, what does the community of SMO users think about setting the default SMO process behavior to self-terminate on unhandled errors?
(I know I can make it configurable... so if there is an absence of widespread consensus, I think this can be resolved quite easily...)