3 ms·

> What would you suggest instead? Implement exceptions. I'm honestly at a loss as to why the Go community hates them so much.

by dom96 7y ago

tandr 7y ago
Go community is big, divided, and has completely different opinions on "exceptions in Go", covering "we have exceptions already, it is called panic()" to "exceptions are evil" Oh, and by the way agreeing on what an exception IS brings whole another dimension into this discussion too. So, I would go as far as "Go community hates them". People have asked for them more than once. No, we did not get them.
- tandr 7y ago
  *wouldn't go as far, sorry
qtplatypus 7y ago
There are a number of good reasons not to like exceptions. And yes I'm fully aware that good coding practices and some implementations can mitigate these problems. * Exceptions create a type of non locality that is hard to reason about. In a language with exceptions every call to a function might result on the calling function exiting. Flow control might jump up serval stack frames unexpectedly. This works against the principles of structured programing and the normal expectation that a function when called will return a value. This means the programer, the compiler and the runtime environment must always take this into account. This can create unexpected behaviour and creates a whole host of special cases for the compiler and runtime. * Uncaught exceptions cause crashes Even when the error is not something that would cause a problem if an exception isn't caught the process will crash. * Exceptions are often too heavy for what they do. In many situations an error is an expected/frequent outcome. Consider a disk based cache of some sort. The cache would attempt to open a file containing th cached result and if the cached result was not found then it would then do the processing to create that result. In this case in most typical exception systems the exception would propagate up the call stack to the exception handler capturing the stack in the process. Once handler is reached all this work is thrown away. * Exceptions create bad error messages Too often I've seen a buggy java process spew stack traces into the logs where a single line error message saying what happened would have made the operator's 2am dealing with emergency much more manageable.

> What would you suggest instead? Implement exceptions. I'm honestly at a loss as to why the Go community hates them so much.

by dom96 7y ago

> What would you suggest instead? Implement exceptions. I'm honestly at a loss as to why the Go community hates them so much.

tandr 7y ago

Go community is big, divided, and has completely different opinions on "exceptions in Go", covering "we have exceptions already, it is called panic()" to "exceptions are evil" Oh, and by the way agreeing on what an exception IS brings whole another dimension into this discussion too. So, I would go as far as "Go community hates them". People have asked for them more than once. No, we did not get them.

tandr 7y ago
*wouldn't go as far, sorry

qtplatypus 7y ago

There are a number of good reasons not to like exceptions. And yes I'm fully aware that good coding practices and some implementations can mitigate these problems. * Exceptions create a type of non locality that is hard to reason about. In a language with exceptions every call to a function might result on the calling function exiting. Flow control might jump up serval stack frames unexpectedly. This works against the principles of structured programing and the normal expectation that a function when called will return a value. This means the programer, the compiler and the runtime environment must always take this into account. This can create unexpected behaviour and creates a whole host of special cases for the compiler and runtime. * Uncaught exceptions cause crashes Even when the error is not something that would cause a problem if an exception isn't caught the process will crash. * Exceptions are often too heavy for what they do. In many situations an error is an expected/frequent outcome. Consider a disk based cache of some sort. The cache would attempt to open a file containing th cached result and if the cached result was not found then it would then do the processing to create that result. In this case in most typical exception systems the exception would propagate up the call stack to the exception handler capturing the stack in the process. Once handler is reached all this work is thrown away. * Exceptions create bad error messages Too often I've seen a buggy java process spew stack traces into the logs where a single line error message saying what happened would have made the operator's 2am dealing with emergency much more manageable.