5 ms·

This is not correct. Exceptions do different things than report an error. They unwind the stack. That's why they are called exceptions and not errors. One impo

by chmike 8y ago

This is not correct. Exceptions do different things than report an error. They unwind the stack. That's why they are called exceptions and not errors. One important benefit of Go's error handling pattern is readability. With exceptions, it's not easy to see who handles it and where. There is indeed less code, and that's nice for the writer, but from the reader perspective, error handling becomes obscure. And from the quality control point if view, this becomes unsafe.

deleted 8y ago
[deleted]
h1d 8y ago
At the cost of making the entire logic's readability less which to me is more important than sometimes getting confused where errors bubble up to. The philosophy is different when, for example the author of Ruby wanted to make coding fun for programmers and does a good job at it and Go is sticking to 'this must be right' approach and breaks some people's heart. Personally I'd appreciate being more 'fun'.
- dfischer 8y ago
  I used ruby for a long time and Go more recently. I think Go is fun. I’m able to read code bases with consistency. In a lot of Ruby apps, I see creative flexing that is unique to that person, or teams style. The fun part is getting code written, and shipped. And it stays fun when it’s maintainable and production ready. I’m having a lot of fun shipping Go code. :) I definitely can understand a codebase a lot faster than a random ruby one. That may be a personal thing but it works for me.
- DJHenk 8y ago
  Depends on your definition of fun, I guess. I personally don't like Ruby because of that fun-factor. In most cases, it makes programming easier for the novice, but more complicated for the experienced. This is because to make it easier for the novice, there are all kinds of constructs that try to make the code imitate normal English. But coding software is a completely different thing than writing text, thus the English-like front is in fact a smoke screen that hides the real gears. A small example would be the unless keyword. It completely throws me of each time I come across it, because it reverses the order of evaluation: Do something, unless condition applies. I read that from left to right, so in my mind "Do something" has already executed, but then I have to go back, because the condition might not apply. This get really 'fun' if the condition is something negative. I like Go just because it way more simple. Even it is a bit more verbose in the error handling, everywhere else it is very minimal and clear.
  - ethelward 8y ago
    That's only the postfix version of unless though, and you could use if the same way. And inversely, you can use unless is its own block, like if.
lucio 8y ago
Let's imagine a syntax-sugared Go... Every function has a hidden "err" return value Every function has an "exceptionExit:" block, by default it does just "return err;" After every function call, an automatic "if err != nil {goto exceptionExit}" is added. You can add an "exception" block to a function, it replaces the default. Now you have function level exceptions in Go just by syntax sugar, without stack unwinding and without requiring new compiler functionality, just syntax sugar.
groestl 8y ago
The parent is correct. Returns also unwind the stack. > One important benefit of Go's error handling pattern is readability I beg to differ, Go's approach is similar to checked exceptions, Java's original sin. And just like checked exceptions, forcing the invoker of a function to handle the error directly is the wrong approach in the vast majority of cases. It just produces code noise and catch/wrap/throw style code, commonly found in old Java enterprise projects. This obsfucates the default path and makes middleware very hard to write. > With exceptions, it's not easy to see who handles it and where. Making errors part of the function signature encourages developers to handle them directly at the call site. Which is where most buggy and unreliable error handling is found. The default approach of safely unwinding the stack until you reach the http handler (or equivalent), returning 500 applies to error codes as well. It should be simple to do, automatic even, so novice programmers write robust code out of the box. Hence exceptions.
- chmike 8y ago
  Seriously, exceptions are very different from returning an error. Confusing error return with checked exception tells it all. A checked exception is just an exception type specification. When you read code with a call to a function returning an error, you see how the error is handled. With exception, unless there is a try/catch close surrounding the call, you don't know where and how an exception is handled. To me, throwing exceptions is like littering the streets. That feels fine for the one who does it, because he assume someone else will take care of the mess. But the problem is taking care of it, who, how when ? With big projects, this strategy is unmanageable. Correctly handled exceptions don't make middle-ware easier to write or more readable. On the contrary. You know that programs are not only http handlers, right ?
  - erik_seaberg 8y ago
    > […] function returning an error, you see how the error is handled. In practice you only see that errors get returned immediately. Most functions rightly give up rather than trying to handle errors because they don't know exactly how or where they're being (re)used.
  - 8y ago
rco8786 8y ago
> They unwind the stack. That's my point. returning the err until some caller above you handles it is unwinding the stack. You're just forced to do it manually at every single level of the stack.
dragonwriter 8y ago
> One important benefit of Go's error handling pattern is readability. Maybe; personally I find it increased clutter that obscures readability (much as do checked exceptions.) > With exceptions, it's not easy to see who handles it and where. Who handles it and where is the one thing that is explicit and readily apparent with unchecked exceptions. What can be harder to see with unchecked exceptions than with error returns or checked exceptions is who (other than the original source) throws it and requires consideration of handling it or ignoring/rethrowing it in the caller.

by chmike 8y ago

deleted 8y ago

[deleted]

h1d 8y ago

At the cost of making the entire logic's readability less which to me is more important than sometimes getting confused where errors bubble up to. The philosophy is different when, for example the author of Ruby wanted to make coding fun for programmers and does a good job at it and Go is sticking to 'this must be right' approach and breaks some people's heart. Personally I'd appreciate being more 'fun'.

dfischer 8y ago
I used ruby for a long time and Go more recently. I think Go is fun. I’m able to read code bases with consistency. In a lot of Ruby apps, I see creative flexing that is unique to that person, or teams style. The fun part is getting code written, and shipped. And it stays fun when it’s maintainable and production ready. I’m having a lot of fun shipping Go code. :) I definitely can understand a codebase a lot faster than a random ruby one. That may be a personal thing but it works for me.
DJHenk 8y ago
Depends on your definition of fun, I guess. I personally don't like Ruby because of that fun-factor. In most cases, it makes programming easier for the novice, but more complicated for the experienced. This is because to make it easier for the novice, there are all kinds of constructs that try to make the code imitate normal English. But coding software is a completely different thing than writing text, thus the English-like front is in fact a smoke screen that hides the real gears. A small example would be the unless keyword. It completely throws me of each time I come across it, because it reverses the order of evaluation: Do something, unless condition applies. I read that from left to right, so in my mind "Do something" has already executed, but then I have to go back, because the condition might not apply. This get really 'fun' if the condition is something negative. I like Go just because it way more simple. Even it is a bit more verbose in the error handling, everywhere else it is very minimal and clear.
- ethelward 8y ago
  That's only the postfix version of unless though, and you could use if the same way. And inversely, you can use unless is its own block, like if.

lucio 8y ago

Let's imagine a syntax-sugared Go... Every function has a hidden "err" return value Every function has an "exceptionExit:" block, by default it does just "return err;" After every function call, an automatic "if err != nil {goto exceptionExit}" is added. You can add an "exception" block to a function, it replaces the default. Now you have function level exceptions in Go just by syntax sugar, without stack unwinding and without requiring new compiler functionality, just syntax sugar.

groestl 8y ago

The parent is correct. Returns also unwind the stack. > One important benefit of Go's error handling pattern is readability I beg to differ, Go's approach is similar to checked exceptions, Java's original sin. And just like checked exceptions, forcing the invoker of a function to handle the error directly is the wrong approach in the vast majority of cases. It just produces code noise and catch/wrap/throw style code, commonly found in old Java enterprise projects. This obsfucates the default path and makes middleware very hard to write. > With exceptions, it's not easy to see who handles it and where. Making errors part of the function signature encourages developers to handle them directly at the call site. Which is where most buggy and unreliable error handling is found. The default approach of safely unwinding the stack until you reach the http handler (or equivalent), returning 500 applies to error codes as well. It should be simple to do, automatic even, so novice programmers write robust code out of the box. Hence exceptions.

chmike 8y ago
Seriously, exceptions are very different from returning an error. Confusing error return with checked exception tells it all. A checked exception is just an exception type specification. When you read code with a call to a function returning an error, you see how the error is handled. With exception, unless there is a try/catch close surrounding the call, you don't know where and how an exception is handled. To me, throwing exceptions is like littering the streets. That feels fine for the one who does it, because he assume someone else will take care of the mess. But the problem is taking care of it, who, how when ? With big projects, this strategy is unmanageable. Correctly handled exceptions don't make middle-ware easier to write or more readable. On the contrary. You know that programs are not only http handlers, right ?
- erik_seaberg 8y ago
  > […] function returning an error, you see how the error is handled. In practice you only see that errors get returned immediately. Most functions rightly give up rather than trying to handle errors because they don't know exactly how or where they're being (re)used.
- 8y ago

rco8786 8y ago

> They unwind the stack. That's my point. returning the err until some caller above you handles it is unwinding the stack. You're just forced to do it manually at every single level of the stack.

dragonwriter 8y ago

> One important benefit of Go's error handling pattern is readability. Maybe; personally I find it increased clutter that obscures readability (much as do checked exceptions.) > With exceptions, it's not easy to see who handles it and where. Who handles it and where is the one thing that is explicit and readily apparent with unchecked exceptions. What can be harder to see with unchecked exceptions than with error returns or checked exceptions is who (other than the original source) throws it and requires consideration of handling it or ignoring/rethrowing it in the caller.