Exceptions don't travel well across boundaries in distributed systems, which is one of the main use cases for Go. Making errors values allows for defining strategies appropriate for the context. Alas most people don't, so code is littered with examples like the one you show.
Yeah, I suppose I don't have much experience with distributed systems and hadn't considered exception handling.
For ActiveRecord (think model validation), I've used the pattern of appending to a list of errors and then doing @errors.any? to determine whether a call was successful or not - quite liked that. It kind of overkill if you want to bail at the first error though, since errors.count will always be 1.
That's a great post, thanks!
We're a place where coders share, stay up-to-date and grow their careers.
Exceptions don't travel well across boundaries in distributed systems, which is one of the main use cases for Go. Making errors values allows for defining strategies appropriate for the context. Alas most people don't, so code is littered with examples like the one you show.
Rob Pike's post on this topc is definitely worth a read: blog.golang.org/errors-are-values
Yeah, I suppose I don't have much experience with distributed systems and hadn't considered exception handling.
For ActiveRecord (think model validation), I've used the pattern of appending to a list of errors and then doing
@errors.any?to determine whether a call was successful or not - quite liked that. It kind of overkill if you want to bail at the first error though, sinceerrors.countwill always be1.That's a great post, thanks!