4 ms·

Panic is not exit. http://golang.org/pkg/os/#Exit http://golang.org/pkg/os/#Exit is exit Panic is throw. Recover is an isomorphism for catch. For the most pa

• NateDad 12y ago
  "In order to ignore error codes in go, you must do so explicitly". - FTFY
  • Tobani 12y ago
    Yeah. The only caveat I'd give is a bit of a stretch. Not explicitly error handling, but you can lookup maps as: j := m["root"] or j, ok := m["root"] Again, this tangential to the subject at hand. But this is the main reason I qualify that statement.
    • NateDad 12y ago
      That's a very good point, actually. It's tricky, because always requiring the latter format is burdensome, especially if the zero value of the map is an ok value for you...
• robryk 12y ago
  > You have to explicitly ignore error codes in go. (Not that you can't handle them incorrectly.) I'm not sure I udnerstand what you mean. I can write: fmt.Fprint(os.Stdout, "Something\n") This returns an error, which I silently discard. Did you mean something else?
  • Tobani 12y ago
    fmt.Fprint(os.Stdout, "Something\n") By itself isn't a valid statement. You try to compile that and you'll get an error saying unused return value. So you'll try: err := fmt.Fprint(os.Stdout, "Something\n") and you could ignore err, but then you'll get a compiler saying err is defined but never used. So you can be like NAH I'm just trying to muck stuff up so I"m going to do this. _ = fmt.Fprint(os.Stdout, "Something\n") Which is explicitly discarding the error much like: try{ fmt.Fprint(os.Stdout, "Something\n") }catch(Throwable t){}
    • robryk 12y ago
      I'm sorry, but that's not true: http://play.golang.org/p/PiMXQkKOef http://play.golang.org/p/PiMXQkKOef
      • Tobani 12y ago
        So it appears you're right. For things for which you don't care about any value returned this is the case. The reason I haven't run into this is for the most part things that can error, they also return a value that matters. You can't use the return value without doing something with the error. http://play.golang.org/p/yreUbxx5Vv http://play.golang.org/p/yreUbxx5Vv So it appears that there is a loophole for things that can error and purely used for side effects.
      • NateDad 12y ago
        This is true, you can drop all return values. However, a lot of functions return a value and an error. If you want to access the value, you need to assign the error to something too. And if you don't then use that error, the compiler will complain about it. For simply dropping all return values on the ground, there are linters that will complain for you: https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck