4 ms·

Even shorter: package main import "io/ioutil" func main() { data, err := ioutil.ReadFile("/etc/ttys") ... printl

by exch 13y ago

Even shorter: package main import "io/ioutil" func main() { data, err := ioutil.ReadFile("/etc/ttys") ... println(string(data)) }

sigzero 13y ago
There is one thing I hate. Go error handling.
- tptacek 13y ago
  It is very explicit and C-like. If, like me, your favorite language is C, it's OK (I agree it's not optimal). If your favorite language has exceptions, it'll annoy you a lot.
- thezilch 13y ago
  Why is that? Compared to? Is it worse than exceptions? f, err := os.Open("/etc/ttys") if err != nil { // handle `err` "f not found" } try: f = open("/etc/ttys") except IOError as err: // handle `err` "f not found" I hate having to sometimes reindent a block of code, not changing any part of the block, because I need to wrap it in a try/except. It really drives me crazy with my obsession to have a clean, revision history.
  - betaclass 13y ago
    With exceptions you can: a) handle the exceptions higher up the call stack b) consolidate error handling code for multiple error generation points With Go you pretty much have to attach a conditional to many calls. Your obsession with clean revision histories is another matter.
    - nknighthb 13y ago
      panic/recover substitute for most reasonable exception use cases.
      - tptacek 13y ago
        Using panic for non-fatal errors is non-idiomatic, isn't it?
        jlgreco 13y ago
        Yeah, but arguably not as non-idiomatic as letting panics cross package boundaries. So long as you keep it all in your package I don't imagine very many people will mind if you use them a tad liberally (use them for things that are not truly exceptional). I think most people who are bothered by Go's error handling are really just bothered by cross-package panics not being idiomatic (and thank god they aren't).
        nknighthb 13y ago
        Define "fatal". Go-the-language and the standard library sometimes panic in situations that are bad but non-fatal for a long-running server process. I have no issue with an argument that a panic making it out of a library meant for general external use is usually a bad thing -- that's not a "reasonable use of exceptions". But my own applications are deliberately structured so that most of the outer layers can safely assume most operations will just work, as inner layers, to which interaction with external libraries is largely confined, will log.Panic() if they don't. It's the right choice 90% or more of the time, and leaves us with shorter, cleaner code. In any case, I severely dislike arguments based on whether something is "idiomatic" or not. It's one thing when you're talking about loops and switches, and something else entirely when you hit someone over the head with it on architectural matters, especially in a language this young.
  - papsosouid 13y ago
    >Is it worse than exceptions? No, but "is it worse than the very worst possible option" isn't a good standard to use. >Compared to? ADTs. >Why is that? Because you can use the value even when an error occurred. The type system should prevent this, as is trivially done in every language with ADTs.
    - thezilch 13y ago
      Well, it's non-obvious what we're comparing it to, so I assumed the most oft compared exceptions. In this case, when opening a file, you can go ahead and use the value and "ignore" the error. Go ahead a run either of the above examples. Notice tptacek explicitly ignores the error. This argument comes up a lot in lieu of or during talk of Generics, so it'd be best for me to defer to those discussions. Unless you or the OP have examples of hating `err` handling not yet described here, opening / reading a file in Go doesn't strike me as a place to take jabs at how errors are handled in Go.
      - papsosouid 13y ago
        I have no idea what you are talking about. The fact that you can ignore the error, including doing so by accident, is the problem. Sum types solved this problem a very long time ago, and there is simply no reason for a language created in the last decade not to have them. It is very simple conceptually, the function should not return a value and an error, because only one of those actually is valid. So it should return a value or an error.

by exch 13y ago

Even shorter: package main import "io/ioutil" func main() { data, err := ioutil.ReadFile("/etc/ttys") ... println(string(data)) }

sigzero 13y ago

There is one thing I hate. Go error handling.

tptacek 13y ago
It is very explicit and C-like. If, like me, your favorite language is C, it's OK (I agree it's not optimal). If your favorite language has exceptions, it'll annoy you a lot.
thezilch 13y ago
Why is that? Compared to? Is it worse than exceptions? f, err := os.Open("/etc/ttys") if err != nil { // handle `err` "f not found" } try: f = open("/etc/ttys") except IOError as err: // handle `err` "f not found" I hate having to sometimes reindent a block of code, not changing any part of the block, because I need to wrap it in a try/except. It really drives me crazy with my obsession to have a clean, revision history.
- betaclass 13y ago
  With exceptions you can: a) handle the exceptions higher up the call stack b) consolidate error handling code for multiple error generation points With Go you pretty much have to attach a conditional to many calls. Your obsession with clean revision histories is another matter.
  - nknighthb 13y ago
    panic/recover substitute for most reasonable exception use cases.
    - tptacek 13y ago
      Using panic for non-fatal errors is non-idiomatic, isn't it?
      - jlgreco 13y ago
        Yeah, but arguably not as non-idiomatic as letting panics cross package boundaries. So long as you keep it all in your package I don't imagine very many people will mind if you use them a tad liberally (use them for things that are not truly exceptional). I think most people who are bothered by Go's error handling are really just bothered by cross-package panics not being idiomatic (and thank god they aren't).
      - nknighthb 13y ago
        Define "fatal". Go-the-language and the standard library sometimes panic in situations that are bad but non-fatal for a long-running server process. I have no issue with an argument that a panic making it out of a library meant for general external use is usually a bad thing -- that's not a "reasonable use of exceptions". But my own applications are deliberately structured so that most of the outer layers can safely assume most operations will just work, as inner layers, to which interaction with external libraries is largely confined, will log.Panic() if they don't. It's the right choice 90% or more of the time, and leaves us with shorter, cleaner code. In any case, I severely dislike arguments based on whether something is "idiomatic" or not. It's one thing when you're talking about loops and switches, and something else entirely when you hit someone over the head with it on architectural matters, especially in a language this young.
- papsosouid 13y ago
  >Is it worse than exceptions? No, but "is it worse than the very worst possible option" isn't a good standard to use. >Compared to? ADTs. >Why is that? Because you can use the value even when an error occurred. The type system should prevent this, as is trivially done in every language with ADTs.
  - thezilch 13y ago
    Well, it's non-obvious what we're comparing it to, so I assumed the most oft compared exceptions. In this case, when opening a file, you can go ahead and use the value and "ignore" the error. Go ahead a run either of the above examples. Notice tptacek explicitly ignores the error. This argument comes up a lot in lieu of or during talk of Generics, so it'd be best for me to defer to those discussions. Unless you or the OP have examples of hating `err` handling not yet described here, opening / reading a file in Go doesn't strike me as a place to take jabs at how errors are handled in Go.
    - papsosouid 13y ago
      I have no idea what you are talking about. The fact that you can ignore the error, including doing so by accident, is the problem. Sum types solved this problem a very long time ago, and there is simply no reason for a language created in the last decade not to have them. It is very simple conceptually, the function should not return a value and an error, because only one of those actually is valid. So it should return a value or an error.