5 ms·

Does anyone else find 4 lines of error checking (log and panic) boiler plate code for every line of functional code a bit tedious?

eta_carinae 14y ago
Annoying as hell, that's what you get when you don't support exceptions.
- eternalban 14y ago
  http://play.golang.org/p/WUxODxK_4r http://play.golang.org/p/WUxODxK_4r
- masklinn 14y ago
  > that's what you get when you don't support exceptions. That's what you get when you refuse to use them anyway. Go has exceptions, there's just a dogma about never using them.
  - skelterjohn 14y ago
    You can't really use panics as exceptions. If you do your code will be strange and hard to work with. This strangeness is fine, because they aren't meant to be used like that. A good rule of thumb is to use panics when it's a programmer error indicating a bug.
  - luriel 14y ago
    Not dogma, just common sense based on experience. Panic() is for truly irrecoverable exceptional situations where you do not expect the caller to catch it.
Evbn 14y ago
You can ignore errors if you want to crash, just like Java.
- wonderzombie 14y ago
  Yes, exactly. If you find the boilerplate tedious, feel free to ignore errors completely. :) For test code it doesn't matter. It is the equivalent of providing no exception handler, or catching Exception or Throwable and doing nothing.
  - reddit_clone 14y ago
    That is not optimal. It not going to crash in the location of first error. It will plough on a bit and crash somewhere else where the bad object/pointer was actually used to perform an illegal operation. Something like a 'die on error' option might be useful for trivial scripts and applications.
    - luriel 14y ago
      When prototyping stuff is trivial to have a fail(err) function that panics in case err is not nil. I sometimes do this, and then remove the fail() function to force myself to properly handle the errors. (Still, often is best to handle the errors as soon as you write the code anyway). The key is that unlike with exceptions, the fact that you are ignoring the error is explicitly stated in the code, is not something that magically might happen. And most importantly, errors are part of the documented API, with exceptions it is rarely documented what exceptions a function might throw, much less what exceptions the functions called by that function might throw. Yes, Go error handling is a bit verbose, but that is a sign of how much better it is than exceptions, without falling into the 'checked exceptions' insanity.
    - wonderzombie 14y ago
      Which is similar to the scenario where you ignore all exceptions and your test script got into a bad state. :) Much as you could write this in Java: catch (Throwable t) { throw new RuntimeException("oh noes"); // or whatever } You could write this in Go: if err != nil { panic("oh noes") }
      - reddit_clone 14y ago
shanemhansen 14y ago
It's annoying, the only thing it has going for it is it's better (in my subjective opinion) than the alternative. In go you can happily ignore an exception by assigning it to _. That's probably a bad idea for a larger piece of code, but for little scripts, go for it. I may be already permanently damaged by go. Every time a function can return an exception I have to stop and ask myself: "self, what should you do if this happens?". I'm starting to think it results in better code. Granted, not every shell script/utility benefits from this level of introspection, but that's what python's for I guess. p.s. Anyone who's had to deal with checked exceptions in java puts up with a crazy about of boiler plate too. p.p.s. Disclaimer I have been professionally employed writing all languages mentioned above, so hopefully I'm relatively unbiased.
- masklinn 14y ago
  > It's annoying, the only thing it has going for it is it's better (in my subjective opinion) than the alternative. Why? There's nothing necessarily wrong about letting it crash, and letting a layer above report the error cleanly. Hell, in Erlang the usage is even to let an other process entirely handle the error. In fact, my opinion would be the complete opposite of yours: checking every single return value (if only to return it to the caller unaltered) is fine for little script, but it's a bad pattern to need for large pieces of code, it's verbose, redundant and unhelpful.
  - papsosouid 14y ago
    >There's nothing necessarily wrong about letting it crash Then do that. You don't have to handle errors, you can ignore them just like you would ignore an exception. The difference is that with an error return value, you are explicitly choosing to ignore it. With exceptions, it is easy to accidently ignore it when you didn't want to. >but it's a bad pattern to need for large pieces of code, it's verbose, redundant and unhelpful. Which is an argument for better error handling, not an argument for exceptions. If go had Maybe and Either, there would be no problem.
    - masklinn 14y ago

eta_carinae 14y ago

Annoying as hell, that's what you get when you don't support exceptions.

eternalban 14y ago
http://play.golang.org/p/WUxODxK_4r http://play.golang.org/p/WUxODxK_4r
masklinn 14y ago
> that's what you get when you don't support exceptions. That's what you get when you refuse to use them anyway. Go has exceptions, there's just a dogma about never using them.
- skelterjohn 14y ago
  You can't really use panics as exceptions. If you do your code will be strange and hard to work with. This strangeness is fine, because they aren't meant to be used like that. A good rule of thumb is to use panics when it's a programmer error indicating a bug.
- luriel 14y ago
  Not dogma, just common sense based on experience. Panic() is for truly irrecoverable exceptional situations where you do not expect the caller to catch it.

Evbn 14y ago

You can ignore errors if you want to crash, just like Java.

wonderzombie 14y ago
Yes, exactly. If you find the boilerplate tedious, feel free to ignore errors completely. :) For test code it doesn't matter. It is the equivalent of providing no exception handler, or catching Exception or Throwable and doing nothing.
- reddit_clone 14y ago
  That is not optimal. It not going to crash in the location of first error. It will plough on a bit and crash somewhere else where the bad object/pointer was actually used to perform an illegal operation. Something like a 'die on error' option might be useful for trivial scripts and applications.
  - luriel 14y ago
    When prototyping stuff is trivial to have a fail(err) function that panics in case err is not nil. I sometimes do this, and then remove the fail() function to force myself to properly handle the errors. (Still, often is best to handle the errors as soon as you write the code anyway). The key is that unlike with exceptions, the fact that you are ignoring the error is explicitly stated in the code, is not something that magically might happen. And most importantly, errors are part of the documented API, with exceptions it is rarely documented what exceptions a function might throw, much less what exceptions the functions called by that function might throw. Yes, Go error handling is a bit verbose, but that is a sign of how much better it is than exceptions, without falling into the 'checked exceptions' insanity.
  - wonderzombie 14y ago
    Which is similar to the scenario where you ignore all exceptions and your test script got into a bad state. :) Much as you could write this in Java: catch (Throwable t) { throw new RuntimeException("oh noes"); // or whatever } You could write this in Go: if err != nil { panic("oh noes") }
    - reddit_clone 14y ago

shanemhansen 14y ago

It's annoying, the only thing it has going for it is it's better (in my subjective opinion) than the alternative. In go you can happily ignore an exception by assigning it to _. That's probably a bad idea for a larger piece of code, but for little scripts, go for it. I may be already permanently damaged by go. Every time a function can return an exception I have to stop and ask myself: "self, what should you do if this happens?". I'm starting to think it results in better code. Granted, not every shell script/utility benefits from this level of introspection, but that's what python's for I guess. p.s. Anyone who's had to deal with checked exceptions in java puts up with a crazy about of boiler plate too. p.p.s. Disclaimer I have been professionally employed writing all languages mentioned above, so hopefully I'm relatively unbiased.

masklinn 14y ago
> It's annoying, the only thing it has going for it is it's better (in my subjective opinion) than the alternative. Why? There's nothing necessarily wrong about letting it crash, and letting a layer above report the error cleanly. Hell, in Erlang the usage is even to let an other process entirely handle the error. In fact, my opinion would be the complete opposite of yours: checking every single return value (if only to return it to the caller unaltered) is fine for little script, but it's a bad pattern to need for large pieces of code, it's verbose, redundant and unhelpful.
- papsosouid 14y ago
  >There's nothing necessarily wrong about letting it crash Then do that. You don't have to handle errors, you can ignore them just like you would ignore an exception. The difference is that with an error return value, you are explicitly choosing to ignore it. With exceptions, it is easy to accidently ignore it when you didn't want to. >but it's a bad pattern to need for large pieces of code, it's verbose, redundant and unhelpful. Which is an argument for better error handling, not an argument for exceptions. If go had Maybe and Either, there would be no problem.
  - masklinn 14y ago