13 ms·
The following line in golang ignores the error: fmt.Println("foo") Compare to a language with exception handling where an exception will get thrown and bu
by apta 6y ago
The following line in golang ignores the error:
fmt.Println("foo")
Compare to a language with exception handling where an exception will get thrown and bubbles up the stack until it either hits a handler, or crashes the program with a stack trace.
And I was referring to accidental ignoring. I've seen variations of the following several times now:
res, err := foo("foo")
if err != nil { ... }
if res != nil { ... }
res, err = foo("bar")
if res != nil { ... }
- Mawr 6y agoUsage of linters fixes this: >The following line in golang ignores the error: fmt.Println("foo") fmt.Println() is blacklisted for obvious reasons, but this: a := func() error { return nil } a() results in: go-lint: Error return value of 'a' is not checked (errcheck) >And I was referring to accidental ignoring. I've seen variations of the following several times now: res, err := foo("foo") if err != nil { ... } if res != nil { ... } res, err = foo("bar") if res != nil { ... } results in: go-lint: ineffectual assignment to 'err' (ineffassign)
- apta 6y ago> fmt.Println() is blacklisted for obvious reasons That's the issue with the language, there are so many special cases for convenience sake, not for correctness sake. It's obvious why it's excluded, but it doesn't make it correct. Do you want critical software written in such a language? Furthermore, does that linter work with something like gorm (https://gorm.io/ https://gorm.io/) and its way of handling errors? It's extremely easy to mis-handle errors with it. It's even a widely used library.
- deleted 6y ago[deleted]
- geodel 6y agoHuh, I have seen enough catch blocks in Java code at work which are totally empty. How is that better than ignoring error?
- apta 6y agoBecause it's an explicit opt-in, as opposed to accidental opt out. And static checking can warn you about empty catch blocks.