Still if you tell say something is generally discouraged you should say why. In this case it’s discouraged because it doesn’t mesh well with go’s error handling.
Still if you tell say something is generally discouraged you should say why. In this case it’s discouraged because it doesn’t mesh well with go’s error handling.
Instead of writing:
result, err := operationFoo(userInput) if err != nil { panic(err }
result, err = operationBar(result) if err != nil { panic(err }
You can create a Process and handle errors only once:
result, err := agency.NewProcess(operationFoo, operationBar).Execute(userInput) // ...
Imagine having 3+ operations, like 5 or 10. That's gonna be some real difference.
All the chained methods like `SetPrompt(...)` returns `agency.Operation` and no error needs to be handled there
Or, I suppose the user must handle exception behavior in their custom `OperationHandler`
2) What wrapping would you add out there? (Wrapping must be added in provider's implementations though)
3) No, user shouldn't and can't handle errors by implementing operation handler. To handle error it simply uses go's native mechanism "v, err := ... ; if err != nil", it just needs to be done once instead of doing so for every operation in the process