4 ms·
Not that I have anything against or for this proposal, I think the focus should be on items which causes daily friction. Example the err check pattern: val
by devnull3 4y ago
Not that I have anything against or for this proposal, I think the focus should be on items which causes daily friction.
Example the err check pattern:
val, err := f()
if err != nil {
return err
}
Now to be fair this was discussed in public sometime back. I don't know what became of it.
- mdaniel 4y agoOr `-Werror` that makes // given func Onoz() error { return errors.New("kaboom") } // when Onoz() // does not compile due to unhandled error Golang has an existing syntax for purposefully eating errors via _ = Onoz() but I've caught innumerable bugs in codebases where the author didn't realize (or care?) that funcs returned error and just swallowed it For a language where an _unused import_ is a compilation error, surely either making error swallowing also a compile error, or (as opt-in behavior) using -Werror as with gcc to say, "no, seriously: no error swallowing permitted" It might require some silliness given the "vendor deps" pattern, but then again, if one of your deps is also careless, maybe that's _exactly_ the circumstances under which you'd want to call timeout
- morelisp 4y agoThe equivalent of '-Werror' in go is using linters, which will detect that.
- mdaniel 4y agoI have seen no such linter[0]; do you have one that you know does that? But, sure, A++ for having to install more stuff when the go compiler considers a different "linter" problem as fatal to the build 0: yes, of course GoLand catches it but prying vim from gophers hands is hard work
- morelisp 4y agohttps://github.com/kisielk/errcheck https://github.com/kisielk/errcheck, which is in most of the combined linter packages by default. We'll agree to disagree about unused imports; imports have can side-effects.