There are three type of errors/exceptions:
external integration exception, eg, exception raised in sub step in shell func, it is already handled using Result.Code, Result.Msg
internal exception, eg, file loading, templating etc, this should be handled by user, need to find a mechanism
panic
This should be an unhandled bug. The UP cmd program should be reported and fixed to deal with the case.
They can be categorized to:
A. exception not restorable, or should not be restored:
For example, the templating Rendering parsing/syntax issue, as this is a fundamental call for a CMD func step, there could be a few of this type of rendering along the processing chaine to result in final result
B. exception could be optionally handlled by user, user could take control of an alternative approach for better result
templating rendering(not a syntax/parsing issue)
resource validation: eg file/url/end point does not exist
So question is: should we need to use a rescue element to deal with it? It is debatable. It is better to deal with better pre-check/validation before blindly invoke any cmd/shell func and rely on resue to recover the mess. There are a few benefits doing so:
Currently, the main external exception is the exception from within the call of shell func.
The shell execution result is wrapped into last_result for convenient access. You can access:
.last_result.Code
.last_result.Output
You can use ignoreError to ignore the error encountered