5 ms·
I cannot think of a language where errors cannot be ignored. In go it is easy to ignore them, but they stick out and can be marked by static analysis. The probl
by dgb23 6y ago
I cannot think of a language where errors cannot be ignored. In go it is easy to ignore them, but they stick out and can be marked by static analysis. The problems you describe are not solved at the language level, but by giving programmers enough time and incentives to write durable code.
- apta 6y agoThe 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.
- umanwizard 6y agoIn rust, errors are difficult to ignore (you need to either allow compiler warnings, which AFAICT nobody sane does, or write something like `let _ = my_fallible_function();` which makes the intent to ignore the error explicit). Perhaps more fundamental: it’s impossible to accidentally use an uninitialized “success” return value when the function actually failed, which is easy to do in C, C++, Go, etc.
- ori_b 6y agoOr .unwrap(), which I see relatively often.
- umanwizard 6y agoThat’s not ignoring errors, it’s explicitly choosing what to do in case of one (crash).