4 ms·

Exception-like is not the same as proper exceptions. From what I've read about it (there's the caveat: I haven't used it yet), the error handling model in Go so

by vilya 16y ago

Exception-like is not the same as proper exceptions. From what I've read about it (there's the caveat: I haven't used it yet), the error handling model in Go sounds pretty badly broken.

papaf 16y ago
the error handling model in Go sounds pretty badly broken Broken in what way and what have you read? I'm genuinely interested. I don't want to end up doing language advocacy for a language I hardly use, but you seem to be confusing error handling with exception handling - something the design of the exception-like mechanism was designed to prevent. As I understand it, in this approach, errors are things you expect to happen (but are errors) and exceptions are things you never anticipated.
- vilya 16y ago
  Calling it error handling was actually a deliberate choice: since defer/panic/recover isn't an exception mechanism, it wouldn't have made sense to call it one. What I've read about it so far is the original "Proposal for an exception-like mechanism" thread on the golang-nuts group [1]; and the "Panic, defer and recover" article referenced in the Go FAQ [2]. If any of the stuff below is misinformed, or just plain wrong, I'd love to hear: Go is a language that I want to like. So now the things I object to: With Go's model, as I understand it, you can call panic with an arbitrary value. To handle that reliably, your deferred block has to check the type and dispatch to appropriate handler code yourself. That's something you get for free with exceptions, where you can generally provide separate catch blocks for different types of exception. When you recover from a panic, the execution of your function is over. So if you have two operations which can panic and you want to be sure both are attempted, you have to wrap each one in a separate function. It also means the only way to tell if a function panicked (in case you need to do further cleanup, say) is by checking the return code - and you'd better hope that everyone is following sensible conventions for what they return there. That leads to another point: Go encourages checking return codes to see if a function failed, whether or not there was a panic. One of the big advances from exceptions, to my mind, was that you no longer had to mingle control flow information with application data. Keeping the two separate makes it easier to write reliable software because it's more self-documenting. On a more subjective note, I find the syntax really clunky. The examples I've seen all seem to wrap the handler code in an anonymous function: defer func() { ... }() I imagine it would get pretty noisy if you were registering several handlers that way (much like event handlers in Java were). I don't necessarily think exceptions are perfect either, just that Go's alternative seems like a step backward. But I'd actually quite like to be shown that I'm wrong about this. [1] http://groups.google.com/group/golang-nuts/browse_thread/thread/1ce5cd050bb973e4/8bc45b58a32aed25?q=defer+panic&lnk=ol&#38 http://groups.google.com/group/golang-nuts/browse_thread/thr...; [2] http://blog.golang.org/2010/08/defer-panic-and-recover.html http://blog.golang.org/2010/08/defer-panic-and-recover.html
uriel 16y ago
Me and many others that have used languages with "proper exceptions" for years are very happy that Go lacks them. Control flow in code with "proper exceptions" often becomes as convoluted as code using COMEFROM. While Go's approach to error handling is not perfect, I find it much clearer and manageable than that in any other language I have used.
enneff 16y ago
"the error handling model in Go sounds pretty badly broken." That is a massive, damning statement. Please don't make such claims without backing them up. Spreading such ignorance is damaging to the project. Go's error handling model is simple: handle the error immediately, panic, or ignore it. A panic can be recovered, similar to catching an exception. Just because you heard someone whining that Go is not like their favourite language doesn't mean you should go around claiming it's "pretty badly broken." What an insult!
- vilya 16y ago
  Given the tone of your post I can't tell whether you're genuine or just trolling, but see my reply to papaf (it was just below, at time of writing) for more details about what I think is broken in it, if you're interested. Of course if you are trolling, then congratulations on getting a response from me.

by vilya 16y ago

Exception-like is not the same as proper exceptions. From what I've read about it (there's the caveat: I haven't used it yet), the error handling model in Go sounds pretty badly broken.

papaf 16y ago

the error handling model in Go sounds pretty badly broken Broken in what way and what have you read? I'm genuinely interested. I don't want to end up doing language advocacy for a language I hardly use, but you seem to be confusing error handling with exception handling - something the design of the exception-like mechanism was designed to prevent. As I understand it, in this approach, errors are things you expect to happen (but are errors) and exceptions are things you never anticipated.

vilya 16y ago
Calling it error handling was actually a deliberate choice: since defer/panic/recover isn't an exception mechanism, it wouldn't have made sense to call it one. What I've read about it so far is the original "Proposal for an exception-like mechanism" thread on the golang-nuts group [1]; and the "Panic, defer and recover" article referenced in the Go FAQ [2]. If any of the stuff below is misinformed, or just plain wrong, I'd love to hear: Go is a language that I want to like. So now the things I object to: With Go's model, as I understand it, you can call panic with an arbitrary value. To handle that reliably, your deferred block has to check the type and dispatch to appropriate handler code yourself. That's something you get for free with exceptions, where you can generally provide separate catch blocks for different types of exception. When you recover from a panic, the execution of your function is over. So if you have two operations which can panic and you want to be sure both are attempted, you have to wrap each one in a separate function. It also means the only way to tell if a function panicked (in case you need to do further cleanup, say) is by checking the return code - and you'd better hope that everyone is following sensible conventions for what they return there. That leads to another point: Go encourages checking return codes to see if a function failed, whether or not there was a panic. One of the big advances from exceptions, to my mind, was that you no longer had to mingle control flow information with application data. Keeping the two separate makes it easier to write reliable software because it's more self-documenting. On a more subjective note, I find the syntax really clunky. The examples I've seen all seem to wrap the handler code in an anonymous function: defer func() { ... }() I imagine it would get pretty noisy if you were registering several handlers that way (much like event handlers in Java were). I don't necessarily think exceptions are perfect either, just that Go's alternative seems like a step backward. But I'd actually quite like to be shown that I'm wrong about this. [1] http://groups.google.com/group/golang-nuts/browse_thread/thread/1ce5cd050bb973e4/8bc45b58a32aed25?q=defer+panic&lnk=ol&#38 http://groups.google.com/group/golang-nuts/browse_thread/thr...; [2] http://blog.golang.org/2010/08/defer-panic-and-recover.html http://blog.golang.org/2010/08/defer-panic-and-recover.html

uriel 16y ago

Me and many others that have used languages with "proper exceptions" for years are very happy that Go lacks them. Control flow in code with "proper exceptions" often becomes as convoluted as code using COMEFROM. While Go's approach to error handling is not perfect, I find it much clearer and manageable than that in any other language I have used.

enneff 16y ago

"the error handling model in Go sounds pretty badly broken." That is a massive, damning statement. Please don't make such claims without backing them up. Spreading such ignorance is damaging to the project. Go's error handling model is simple: handle the error immediately, panic, or ignore it. A panic can be recovered, similar to catching an exception. Just because you heard someone whining that Go is not like their favourite language doesn't mean you should go around claiming it's "pretty badly broken." What an insult!

vilya 16y ago
Given the tone of your post I can't tell whether you're genuine or just trolling, but see my reply to papaf (it was just below, at time of writing) for more details about what I think is broken in it, if you're interested. Of course if you are trolling, then congratulations on getting a response from me.