5 ms·

Use go for a few month, loving it. but I miss not having exception compare to Python. Is the golang spec still tightly controlled by 3 wisemen in Google and n

by srcmap 12y ago

Use go for a few month, loving it. but I miss not having exception compare to Python. Is the golang spec still tightly controlled by 3 wisemen in Google and no feature is allowed to add to the language without all three in total agreement? BTW, I like 98% of their language decide choices and absolutely LOVE the compilation speed of the program.

NateDad 12y ago
No, it's not controlled by them anymore. Possibly in the early days it was, but now it's much more community controlled. You'll never get exceptions in Go. No one who has used go for a significant period of time wants exceptions. Error values are far superior (given the other features of the language, like multiple returns and interfaces for the error types). You should continue to use Go, I don't think you'll miss exceptions after long. I understand the view, though... first time I saw Go I thought "No exceptions? Pass!". But I got over it, and now I've seen the error of my ways :) There's an amazing freedom that comes with knowing that random functions you call can't exit your function without your control.
- codygman 12y ago
  Sum types and monads are very useful if you believe that errors as values are far superior, you should check them out.
- acdha 12y ago
  > You'll never get exceptions in Go. No one who has used go for a significant period of time wants exceptions If by exception you mean Java's implementation, yes. If by exception you mean not allowing programmers to ignore error values, as most Go programs seems to do at least once, no. I think most of this could be solved easily by either a compiler option or golint rule flagging any time someone does the classic `res, _ := foo()` punt without checking the value before the end of the block or the next time that variable is assigned to. That'd satisfy the “stop repeating C's mistakes” goal most people have without requiring the other changes which true exceptions would require.
  - NateDad 12y ago
    > think most of this could be solved easily by either a compiler option or golint rule You mean like errcheck? https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck I'm not sure if it can find spots where people intentionally throw away an error like in val, _ := foo() Usually people are more concerned with places where people accidentally fail to realize there's an error returned at all, like this: func foo() error { ... } foo() // errcheck finds this However, it should be possible to find errors assigned to underscores, and thus detect that case.
    - acdha 12y ago
      Ideally that'd move into the standard suite and you'd have to do something like compile with --repeat-the-mistakes-of-c to skip it. I've noticed most of the intention error punts in dense code where it looked like someone got tired of repeating checks and only checked the errors which happened while they were working. I'd bet a read-before-overwrite policy on _ would catch mostly infrequent environmental failures (i.e. the kind of stuff which only breaks when you're out of space, file handles, etc.).
      - NateDad 12y ago
        Anyone who intentionally throws away errors because they "got tired" of checking errors, isn't someone I'd want on my team, and their code is not something I'd want to depend on, regardless of the language. Hopefully it would get caught in code review. But yes, it would be nice if go vet or go lint caught this syuff. Luckily, someone else wrote errcheck, and that's good enough.

by srcmap 12y ago

NateDad 12y ago

No, it's not controlled by them anymore. Possibly in the early days it was, but now it's much more community controlled. You'll never get exceptions in Go. No one who has used go for a significant period of time wants exceptions. Error values are far superior (given the other features of the language, like multiple returns and interfaces for the error types). You should continue to use Go, I don't think you'll miss exceptions after long. I understand the view, though... first time I saw Go I thought "No exceptions? Pass!". But I got over it, and now I've seen the error of my ways :) There's an amazing freedom that comes with knowing that random functions you call can't exit your function without your control.

codygman 12y ago
Sum types and monads are very useful if you believe that errors as values are far superior, you should check them out.
acdha 12y ago
> You'll never get exceptions in Go. No one who has used go for a significant period of time wants exceptions If by exception you mean Java's implementation, yes. If by exception you mean not allowing programmers to ignore error values, as most Go programs seems to do at least once, no. I think most of this could be solved easily by either a compiler option or golint rule flagging any time someone does the classic `res, _ := foo()` punt without checking the value before the end of the block or the next time that variable is assigned to. That'd satisfy the “stop repeating C's mistakes” goal most people have without requiring the other changes which true exceptions would require.
- NateDad 12y ago
  > think most of this could be solved easily by either a compiler option or golint rule You mean like errcheck? https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck I'm not sure if it can find spots where people intentionally throw away an error like in val, _ := foo() Usually people are more concerned with places where people accidentally fail to realize there's an error returned at all, like this: func foo() error { ... } foo() // errcheck finds this However, it should be possible to find errors assigned to underscores, and thus detect that case.
  - acdha 12y ago
    Ideally that'd move into the standard suite and you'd have to do something like compile with --repeat-the-mistakes-of-c to skip it. I've noticed most of the intention error punts in dense code where it looked like someone got tired of repeating checks and only checked the errors which happened while they were working. I'd bet a read-before-overwrite policy on _ would catch mostly infrequent environmental failures (i.e. the kind of stuff which only breaks when you're out of space, file handles, etc.).
    - NateDad 12y ago
      Anyone who intentionally throws away errors because they "got tired" of checking errors, isn't someone I'd want on my team, and their code is not something I'd want to depend on, regardless of the language. Hopefully it would get caught in code review. But yes, it would be nice if go vet or go lint caught this syuff. Luckily, someone else wrote errcheck, and that's good enough.