4 ms·

Error handling does not obscure the business logic, it is very much part of the business logic.

by PuerkitoBio 11y ago

jacques_chester 11y ago
If your business is handling full disks and HTTP timeouts, sure, exceptions and business logic are the same.
- jerf 11y ago
  The further away from a "network server" you get, the less appealing Go gets. It's a general purpose language, but it's not entirely wrong to think of it as a DSL for writing network servers that happens to be useful for other some things. Why doesn't lack of generics kill Go? Well, if you're working in Go's wheelhouse, []byte actually covers a lot of things and you're rarely that far away from it, because you're about to read or write a []byte real soon now. (I don't mean you always have one literally in hand, you probably marshaled in into a struct, just that you're often very close to either reading or writing it.) Why does it work to have this error handling in Go? Well, when writing network servers or other basic cloud infrastructure, actually a lot of the errors require different handling on a case-by-case basis. Big ol' exception blocks around the whole operation are often hiding bugs, or at the very least, suboptimal exception handling. By contrast, when you're not writing the code to do all the nitty-gritty network operations it's a level of detail you don't want or need. I think every single posted "success story" I've seen for Go has been a network server. I don't think I've ever seen one about how it really cleaned up my Android app, or how my game development was crashing and burning until I switched it to Go. I don't think this is a coincidence, nor do I expect to see one anytime soon, the recent Android support notwithstanding.
moe 11y ago
Error handling does obscure the business logic when, as in Go, nearly every operation needs to be followed by a boilerplate guard clause. Other languages (e.g. Java) have solved this problem quite elegantly over a decade ago with the introduction of Checked Exceptions[1]. Since this is the pattern that every Go program ends up emulating anyway, Google could save everyone a lot of work by just baking it into the language. In the eternal words of Larry Wall: The computer should be doing the hard work. That's what it's paid to do, after all. [1] https://en.wikipedia.org/wiki/Exception_handling#Checked_exceptions https://en.wikipedia.org/wiki/Exception_handling#Checked_exc...
- fooster 11y ago
  Sorry, but if you have every operation followed by a guard clause you are doing it wrong. For example, https://blog.golang.org/errors-are-values https://blog.golang.org/errors-are-values
  - jacques_chester 11y ago
    This just shows that, to avoid having do-and-check after every operation, the provider needs to invent several idioms because it's tedious to the consumer. But now the consumer needs to know multiple idioms and recognise when they are being used. And the reader of the consumer code needs to know that the normal `err != nil` idiom is not being followed. All of which requires everyone involved to do more reading of source code than a "throws" line. How is this simpler than having a single, universal concept of exception handling?
  - ivank 11y ago
    > https://blog.golang.org/errors-are-values https://blog.golang.org/errors-are-values The "helper" function there introduces 10 lines of code (per function in which you want it), and doesn't even work if you call anything besides that one `write` in sequence.
  - moe 11y ago
    Your link describes (and encourages) exactly the laborious emulation of Checked Exceptions that I was talking about in my above comment. It doesn't make the guard clauses disappear. It merely forces the programmer to manually aggregate them at a higher level with even more boilerplate code.
    - mahyarm 11y ago
      If my guard clause is doing the same thing for 20 lines, it increases readability. Could be an optimization point too!
  - lmm 11y ago
    That's the right approach, but it's still decades behind what a decent programming language would give you for free. You have to copy-paste that "errWriter" definition for every possibly-error-raising method that you want to call, because go has no generics. If you want to write to two different writers, let alone a list of them, then you have to go back to the function-and-variable version, which is very boilerplatey and impossible to reason about when refactoring.
pcwalton 11y ago
> Error handling does not obscure the business logic, it is very much part of the business logic. That's why it's nice when the language provides tools to make it more likely to be correct.

Error handling does not obscure the business logic, it is very much part of the business logic.

jacques_chester 11y ago

If your business is handling full disks and HTTP timeouts, sure, exceptions and business logic are the same.

jerf 11y ago
The further away from a "network server" you get, the less appealing Go gets. It's a general purpose language, but it's not entirely wrong to think of it as a DSL for writing network servers that happens to be useful for other some things. Why doesn't lack of generics kill Go? Well, if you're working in Go's wheelhouse, []byte actually covers a lot of things and you're rarely that far away from it, because you're about to read or write a []byte real soon now. (I don't mean you always have one literally in hand, you probably marshaled in into a struct, just that you're often very close to either reading or writing it.) Why does it work to have this error handling in Go? Well, when writing network servers or other basic cloud infrastructure, actually a lot of the errors require different handling on a case-by-case basis. Big ol' exception blocks around the whole operation are often hiding bugs, or at the very least, suboptimal exception handling. By contrast, when you're not writing the code to do all the nitty-gritty network operations it's a level of detail you don't want or need. I think every single posted "success story" I've seen for Go has been a network server. I don't think I've ever seen one about how it really cleaned up my Android app, or how my game development was crashing and burning until I switched it to Go. I don't think this is a coincidence, nor do I expect to see one anytime soon, the recent Android support notwithstanding.

moe 11y ago

Error handling does obscure the business logic when, as in Go, nearly every operation needs to be followed by a boilerplate guard clause. Other languages (e.g. Java) have solved this problem quite elegantly over a decade ago with the introduction of Checked Exceptions[1]. Since this is the pattern that every Go program ends up emulating anyway, Google could save everyone a lot of work by just baking it into the language. In the eternal words of Larry Wall: The computer should be doing the hard work. That's what it's paid to do, after all. [1] https://en.wikipedia.org/wiki/Exception_handling#Checked_exceptions https://en.wikipedia.org/wiki/Exception_handling#Checked_exc...

fooster 11y ago
Sorry, but if you have every operation followed by a guard clause you are doing it wrong. For example, https://blog.golang.org/errors-are-values https://blog.golang.org/errors-are-values
- jacques_chester 11y ago
  This just shows that, to avoid having do-and-check after every operation, the provider needs to invent several idioms because it's tedious to the consumer. But now the consumer needs to know multiple idioms and recognise when they are being used. And the reader of the consumer code needs to know that the normal `err != nil` idiom is not being followed. All of which requires everyone involved to do more reading of source code than a "throws" line. How is this simpler than having a single, universal concept of exception handling?
- ivank 11y ago
  > https://blog.golang.org/errors-are-values https://blog.golang.org/errors-are-values The "helper" function there introduces 10 lines of code (per function in which you want it), and doesn't even work if you call anything besides that one `write` in sequence.
- moe 11y ago
  Your link describes (and encourages) exactly the laborious emulation of Checked Exceptions that I was talking about in my above comment. It doesn't make the guard clauses disappear. It merely forces the programmer to manually aggregate them at a higher level with even more boilerplate code.
  - mahyarm 11y ago
    If my guard clause is doing the same thing for 20 lines, it increases readability. Could be an optimization point too!
- lmm 11y ago
  That's the right approach, but it's still decades behind what a decent programming language would give you for free. You have to copy-paste that "errWriter" definition for every possibly-error-raising method that you want to call, because go has no generics. If you want to write to two different writers, let alone a list of them, then you have to go back to the function-and-variable version, which is very boilerplatey and impossible to reason about when refactoring.

pcwalton 11y ago

> Error handling does not obscure the business logic, it is very much part of the business logic. That's why it's nice when the language provides tools to make it more likely to be correct.