4 ms·

"Good exception handling style in languages with sane exceptions normally means almost never catching exceptions except for high level orchestration routines; r

by NateDad 12y ago

"Good exception handling style in languages with sane exceptions normally means almost never catching exceptions except for high level orchestration routines; reacting to unwinding by cleaning up resources; and generally taking a transactional approach to operations." I agree. Except that is really really really hard. How does your orchestration routine know to close the file handle that was opened 6 levels deep in the code? How does it know to return 404 not found to the request that was being handled 4 levels deep? It can't, and if it does, then you're breaking encapsulation. The reality of the situation is that the only place where you have the knowledge to clean up after a function is inside that function. I suppose in theory you could write a whole crapload more code to create auto-clean-up objects and transactional frameworks.... and that'll take a lot longer and be a lot buggier, and be a lot less flexible than just handling the error near to where it was produced with boring, straight-forward code, which is how it works in Go.

dragonwriter 12y ago
> Except that is really really really hard. How does your orchestration routine know to close the file handle that was opened 6 levels deep in the code? It doesn't need to. Which is why "never catching exceptions except for high-level orchestration routines" is a separate point from "reacting to unwinding by cleaning up resources". What is being said is that, in good exception handling style, Orchestration routines use try/except (they might use "finally" if they also have local resources to clean up), and lower-level routines use try/finally without "except". > and that'll take a lot longer and be a lot buggier, and be a lot less flexible than just handling the error near to where it was produced with boring, straight-forward code, which is how it works in Go. With Go, you pretty much do the same thing -- lower level code cleans up its own resources (with defer in place of finally) and will propagates errors up in the same circumstances that code would in other languages (with explicitly error returns rather than implicit propagation of exceptions), and higher level orchestration routines are mostly where you do something more with the error returns.
- NateDad 12y ago
  OK, so I don't think we're disagreeing at all then, except possibly about the difficulty / commonality of writing the correct exception handling code.
  - dragonwriter 12y ago
    I think its difficult to do right and frequently done wrong. I'm just not completely convinced that Go makes that significantly better (there is an advantage to being more explicit, but it comes at the cost of making what is usually right -- propagating errors back up the chain -- easy to omit, and lots of sample code silently swallows errors to avoid distraction, which has value for what it is trying to teach but might incidentally also breed bad habits.) It probably makes the most common mistakes in error handling in Go different than with languages where the preferred method is more "traditional" exceptions, because the easiest mistakes to make are different.
barrkel 12y ago
Cleanup can be done with techniques like try/finally, using-blocks, closure nesting like Ruby, RAII like C++, or defer like Go - all completely orthogonal to checking for errors and returning.

by NateDad 12y ago

dragonwriter 12y ago

> Except that is really really really hard. How does your orchestration routine know to close the file handle that was opened 6 levels deep in the code? It doesn't need to. Which is why "never catching exceptions except for high-level orchestration routines" is a separate point from "reacting to unwinding by cleaning up resources". What is being said is that, in good exception handling style, Orchestration routines use try/except (they might use "finally" if they also have local resources to clean up), and lower-level routines use try/finally without "except". > and that'll take a lot longer and be a lot buggier, and be a lot less flexible than just handling the error near to where it was produced with boring, straight-forward code, which is how it works in Go. With Go, you pretty much do the same thing -- lower level code cleans up its own resources (with defer in place of finally) and will propagates errors up in the same circumstances that code would in other languages (with explicitly error returns rather than implicit propagation of exceptions), and higher level orchestration routines are mostly where you do something more with the error returns.

NateDad 12y ago
OK, so I don't think we're disagreeing at all then, except possibly about the difficulty / commonality of writing the correct exception handling code.
- dragonwriter 12y ago
  I think its difficult to do right and frequently done wrong. I'm just not completely convinced that Go makes that significantly better (there is an advantage to being more explicit, but it comes at the cost of making what is usually right -- propagating errors back up the chain -- easy to omit, and lots of sample code silently swallows errors to avoid distraction, which has value for what it is trying to teach but might incidentally also breed bad habits.) It probably makes the most common mistakes in error handling in Go different than with languages where the preferred method is more "traditional" exceptions, because the easiest mistakes to make are different.

barrkel 12y ago

Cleanup can be done with techniques like try/finally, using-blocks, closure nesting like Ruby, RAII like C++, or defer like Go - all completely orthogonal to checking for errors and returning.