5 ms·

From experience of running big production web apps, you need to get error handling right regardless of how tedious it might be. A recent issue where one of our

From experience of running big production web apps, you need to get error handling right regardless of how tedious it might be. A recent issue where one of our developers ate an exception cost us 12 days of developer time. Another historical issue where the error handling and return codes weren't understood and handled correctly threw 500mb of stack dumps a minute and took our logging system out. Spent the time to get it right :)

justinsb 13y ago
Totally agree, and if Go used exceptions I would probably think it perfect. I added an edit to my comment to avoid the implication you picked up on!
- gngeal 13y ago
  How do you propose to make exceptions work in the presence of large number of cooperating goroutines? As in, there's no implicit control flow the way you have it in "less-threaded" languages.
  - justinsb 13y ago
    I don't believe that's a problem; goroutines still have a stack, they just aren't always assigned to an OS thread. At least that's my understanding. Go even has exceptions, it just doesn't usually use them. Can you explain what you think the problem is with supporting exceptions? You raise a good point though, in that there is a valid question of "how would you introduce exceptions into the language / runtime". I think the answer is that the err return value can become implicit. Throwing an exception is the equivalent of "return _, err". Invoking a function that can throw an exception is done by not checking the err return; if an exception is thrown/returned and not checked then it is immediately rethrown (return _,err) in an implicit method. try/catch should be easy to introduce, although the semantics of e.g. "defer" could be tricky.
  - pcwalton 13y ago
    Go has exceptions already: panic and recover. These are equivalent to exceptions (formally so even, in that exceptions could be macro-expanded to panic and recover, and also the other way round).
  - dragonwriter 13y ago
    > How do you propose to make exceptions work in the presence of large number of cooperating goroutines? Exceptions propagate up the call stack within a goroutine, and then, if not recovered within the goroutine that raised them, crash the whole program. (I cheated a bit -- that's how go already handles exceptions, which it calls "panics". The difference between go and, say, Java is that the core and standard library don't panic as much as Java's throws exceptions, leaving the decision to panic to user code more often.)
- pkulak 13y ago
  I like not having exceptions (that are widely used). It's easier to reason about your code. It's, let's just say, "stressful", to know that any line of code you write could potentially blow up and start re-winding the whole stack. Especially in a language like Java that doesn't have stack objects with destructors. You have to indent everything 30 lines in, with finally blocks all over the place. It turns into a mess. Go has a bunch of "if err != nil"s, but for some reason those are less objectionable to me. I feel in control with those. And the code runs down the page, not to the right.

justinsb 13y ago

Totally agree, and if Go used exceptions I would probably think it perfect. I added an edit to my comment to avoid the implication you picked up on!

gngeal 13y ago
How do you propose to make exceptions work in the presence of large number of cooperating goroutines? As in, there's no implicit control flow the way you have it in "less-threaded" languages.
- justinsb 13y ago
  I don't believe that's a problem; goroutines still have a stack, they just aren't always assigned to an OS thread. At least that's my understanding. Go even has exceptions, it just doesn't usually use them. Can you explain what you think the problem is with supporting exceptions? You raise a good point though, in that there is a valid question of "how would you introduce exceptions into the language / runtime". I think the answer is that the err return value can become implicit. Throwing an exception is the equivalent of "return _, err". Invoking a function that can throw an exception is done by not checking the err return; if an exception is thrown/returned and not checked then it is immediately rethrown (return _,err) in an implicit method. try/catch should be easy to introduce, although the semantics of e.g. "defer" could be tricky.
- pcwalton 13y ago
  Go has exceptions already: panic and recover. These are equivalent to exceptions (formally so even, in that exceptions could be macro-expanded to panic and recover, and also the other way round).
- dragonwriter 13y ago
  > How do you propose to make exceptions work in the presence of large number of cooperating goroutines? Exceptions propagate up the call stack within a goroutine, and then, if not recovered within the goroutine that raised them, crash the whole program. (I cheated a bit -- that's how go already handles exceptions, which it calls "panics". The difference between go and, say, Java is that the core and standard library don't panic as much as Java's throws exceptions, leaving the decision to panic to user code more often.)
pkulak 13y ago
I like not having exceptions (that are widely used). It's easier to reason about your code. It's, let's just say, "stressful", to know that any line of code you write could potentially blow up and start re-winding the whole stack. Especially in a language like Java that doesn't have stack objects with destructors. You have to indent everything 30 lines in, with finally blocks all over the place. It turns into a mess. Go has a bunch of "if err != nil"s, but for some reason those are less objectionable to me. I feel in control with those. And the code runs down the page, not to the right.