When do we really use application error details field

Community Support
,
1

Hi,
I have started to use temporal for our business workflows. However, wrt to error propagation I didn’t get a clear answer as to when should we use details ?

It will be helpful someone can shed some light here maybe with some example scenarios ?

// NewApplicationErrorWithCause creates new instance of retryable *ApplicationError with message, type, cause, and optional details.
// Use ApplicationError for any use case specific errors that cross activity and child workflow boundaries.
// errType can be used to control if error is retryable or not. Add the same type in to RetryPolicy.NonRetryableErrorTypes
// to avoid retrying of particular error types.
func NewApplicationErrorWithCause(message, errType string, cause error, details ...interface{}) error {
	return internal.NewApplicationError(message, errType, false, cause, details...)
}
3

You can provide details for example if you need to make fine-grained decisions in your workflow error handling logic.
Super simple sample could be lets say your activity deals with users and have something like:

type appUser struct {
	Name string
	Age  int
}

and lets say in activity code you are processing

myUser := appUser{"User Name", 33}

in your activity:

return temporal.NewApplicationError("User error", "User Error Type", myUser)

In your workflow code then when you handle activity failure you can get out these details something like:

err := workflow.ExecuteActivity(...).Get(...)
if err != nil {
	var appErr *temporal.ApplicationError
	errors.As(err, &appErr)
	var user appUser
	if err := appErr.Details(&user); err != nil {
		// error converting details from payload
	}
       // make decision based on user name/age if needed...
}

Hope this helps

4

Yes. Thanks a lot! :grinning: