> Because it encourages nesting function calls, which is harder for a human to parse than separate statements across lines.
I absolutely agree. Beyond the human parsing aspect it also makes commit changes easier to reason about and review. I want functionality to be limited per-line and view the ability to combine a lot of functionality into one line as a liability more than a benefit.
Go's error handling isn't carefree or hands-off, but that's because error handling is serious. Especially in network code and cryptography.
I really dislike method chaining. I'd much rather have 5 lines than 5 chained methods. If that's too much to read, you can always encapsulate it in a well-named function.
not if each one can fail. What if call #1 and call #3 can return the same error.. how does the caller know which one failed? This is the same as wrapping a bunch of calls with a catch (Exception) ... you lose context of what failed and can't behave differently for different failures. All you can do is perform a generic "something went wrong" behavior.
Interestingly you _can_ implement method chaining to require a terminal method call i.e. err := GetFoo().SetBar(1).SetBaz(2).Run() and then each chained method would set an error property in the object and if err!=nil then do nothing but return the object, and then the last method could return the error value.
That said, I am not a huge fan of fluent interfaces. I much prefer passing in a struct as an "args" parameter, in most case (but not all.)
I absolutely agree. Beyond the human parsing aspect it also makes commit changes easier to reason about and review. I want functionality to be limited per-line and view the ability to combine a lot of functionality into one line as a liability more than a benefit.
Go's error handling isn't carefree or hands-off, but that's because error handling is serious. Especially in network code and cryptography.