5 ms·

> If it was strictly inferior, why would a modern language be designed that way golang is not a modern language (how old it is is irrelevent), and the people

• fooster 6y ago
  Error handling is hard, period. Error handling in go is no worse than any other language, and in most ways it is better being explicit and non-magic. > people who designed it did not have a proper language design background Irrelevant. > It's just bad language design. try { ... } catch(Exception ex) { ... }
  • apta 6y ago
    > try { ... } catch(Exception ex) { ... } The error here is explicitly handled, and cannot be accidentally ignored. Unlike golang where it's quite easy for errors to go ignored accidentally.
    • hactually 6y ago
      because it has try/catch. Without that (which would be similar to not checking the err in go) it explodes or throws to a layer up that may not expect it. Each language has its wonks.
      • apta 6y ago
        > Without that (which would be similar to not checking the err in go) it explodes or throws to a layer up that may not expect it. It's not similar to that at all. Without it, the exception bubbles up until it gets caught somewhere, or crashes the program with a useful stacktrace. With golang, it just goes undetected, and the code keeps running with corrupt state, without anyone knowing any better.
    • fooster 6y ago
      Nevertheless, this is how it is mostly done in Java. I haven't used eclipse in eons, but last time I did it even generated this code. If you care with go, use errcheck.
      • apta 6y ago
        Does errcheck work well with gorm (https://gorm.io/ https://gorm.io/) and it's way of returning errors? This is not an obscure library, it's quite widely used.
        • ori_b 6y ago
          Does any language save you from explicitly screwing up error handling? Gorm is doing the Go equivalent of: class Query { class QueryResult { Exception error; Value result; } public QueryResult query() { try { return doThing(); } catch(Exception e){ return new QueryResult(error, null); } } } Gorm is going out of its way to make error handling suck.
          • apta 6y ago
            > Does any language save you from explicitly screwing up error handling? It's about the default error handling method being sane. In exception based languages, an unhandled error bubbles up until it reaches a handler, or it crashes the program with a stacktrace. Compare to what golang does, it's somewhat easy to accidentally ignore or overwrite errors. This leads to silent corruption of state, much worse than crashing the program outright.
            • ori_b 6y ago
              > It's about the default error handling method being sane. Gorm isn't using the default error handling.
              • apta 6y ago
  • entha_saava 6y ago
    Exceptions don't lead to silent but dangerous and hard to debug errors. The program fails if exception is not handled.
• 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 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 ago
      Usage 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