3 ms·
Method chaining is a coding idiom. It’s kind of silly to say an idiom isn’t idiomatic. I know I’m being pedantic though. Still if you tell say something is gen
by onionisafruit 3y ago
Method chaining is a coding idiom. It’s kind of silly to say an idiom isn’t idiomatic. I know I’m being pedantic though.
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.
- white_dragon88 3y ago[flagged]
- emil14 3y agoActually error handling is much easier with agency's Processes (pipelines) 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
- huac 3y agoI would, at the very least, wrap the errors being returned inside the process function https://github.com/neurocult/agency/blob/14b14e50a75701893886782bc8355fd58e3978e8/agency.go#L41 https://github.com/neurocult/agency/blob/14b14e50a7570189388... Or, I suppose the user must handle exception behavior in their custom `OperationHandler`
- emil14 3y ago1) You said about process but pointed to operation 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