4 ms·
I don't seem to understand what about returning error values stops any flexibility. I have built several things in Golang, and you absolutely have the ability t
by huntaub 12y ago
I don't seem to understand what about returning error values stops any flexibility. I have built several things in Golang, and you absolutely have the ability to continue to return error values ("bubbling up") until a function has the ability to handle or silence it.
I get the personal preference one way or another, but can you go into more detail about what specific features one loses with Go's approach?
- randallsquared 12y agoAnd, in fact, bubbling errors up is very common in my code: func (t *Thing) Delete() error { count, err := db.Delete(t) if err != nil { return err } if count != 1 { return errors.New("delete Thing didn't delete 1 row? count: " + string(count)) } return nil }
- esailija 12y agoIndeed the majority of the time the correct way to handle an error is to propagate it up to the caller...no shit. which is why requiring manual plumbing everywhere to do just that is ridiculous. And forgetting this manual check even once is devastating. And exceptions are not the only thing that do this automatically for you, so this is just flat out horrible design decision.