4 ms·

> are more about having a framework of allowing inner/library code to drop the ball and run away screaming, without making more of a mess. It also allows the c

> are more about having a framework of allowing inner/library code to drop the ball and run away screaming, without making more of a mess. It also allows the calling function to ignore the mess and hope that something further up the call-chain will deal with it. Exceptions circumvent the normal control-flow of a program, and that makes code less obvious to follow. When I see foo calling bar() in go, I know where, and if, errors returned by the function are being handled, just by looking at foo. When I see foo calling bar() in Python, and there is no try-except block in foo, I have no idea what happens to any errors that bar may return. I now have to check everyting that calls foo, which may be multiple other places, each of which could have a different Exception handling, or none, in which case I have to also check all the callers of that caller of foo, etc. And even if there is a try-except, I have to check whether except catches the correct TYPE, so now I also need to be aware of the different types of Exceptions bar may raise ... which in turn depends on everything that bar calls, and how bar itself handles these calls, etc. Yes, error handling in Go is verbose. Yes, it would be nice if it offeres a little syntactic sugar to improve that. But error handling in Go is also obvious.

joshuamorton 4y ago
> And even if there is a try-except, I have to check whether except catches the correct TYPE, so now I also need to be aware of the different types of Exceptions bar may raise ... which in turn depends on everything that bar calls, and how bar itself handles these calls, etc. Why? Keep in mind in go, you almost certainly don't check the type of the error. Why hold python to a hire standard (or the opposite: why don't you pass errors with types in golang, and handle errors of only a particular type or set of types?) The answer, in both cases, is of course the same: errors are almost always handled in one of two cases: basically at the callsite (either at the callsite or in the parent function), or they are handled in "main" in some form of catchall. Exceptions are really great for this. You very much don't worry about the things that might be thrown by a child of a child of a child of foo() that you call, because the abstraction shows that you shouldn't care (unless perhaps foo documents explicitly a particular function it throws). You don't need to waste code or mindshare on something you really don't care about. In go however, you do!
- usrbinbash 4y ago
  > Why? Because unless the caller of foo uses a catchall, it may not actually catch the exception raised by bar. Lets say bar opens a file, and callerOfFoo says `except FileNotFoundError:` ... what if bar opens a file that exists with insufficient Permissions? Then it's `PermissionError`, and callerOfFoo won't catch it. Sure, its possible that callerOfFoo is prepared for that, but my point is, I don't know that unless I check its code.
  - joshuamorton 4y ago
    But again, why do you care?
    - dementiapatien 4y ago
      Because I can visualize Go errors completely. They're simple links from one place to another. They are straight fibers connecting my modules and functions to each other. They always work exactly like I expect them to. With python and other exception based languages? I have made hundreds of commits in my lifetime after being surprised that some random 3rd party library throws a nonstandard exception and breaks all sensible control flow that everybody assumed was happening.
      - joshuamorton 4y ago
        This is the reverse of the issue that the parent mentioned though! Consider a go function foo which returns some value and an error. What can you do with that error? You mention control flow being broken by python and others, but the control flow of def myfunc(): if foo(): do_a() else: do_b() and def myfunc(): try: cond = foo() except: raise if cond: do_a() else: do_b() and func myfunc() err { cond, err := foo() if err != nil { return err } if cond { do_a() } else { do_b() } Are all the same! And you can't do anything different in them, because in go, you have no knowledge about the error. Is it aa temp error you should retry? Who knows, are you going to parse the error string to figure it out? The only think you can do in go to an error from some library function is pass the error, possibly adding some additional context, because otherwise you may be mishandling the error. In exception based languages the "pass the error" case is done for you, but if you do want to retry retriable errors, you can actually use a language feature to know that. In go, you have to hope the library creator created an interface (and that all of the possible errors that could percolate up have compatible error-extension interfaces!) that includes some kind of type information, which almost no one does. You're talking about "sensible" control flow, but go doesn't have it!
code_runner 4y ago
Things can still panic in go. Error handling for an API etc usually make the most sense in a central location (some middleware etc) so why would I check that each and every function call was successful. I do like go, but the error handling is hardly the best thing about it. It’s just different. Neither is wrong.
- usrbinbash 4y ago
  > Things can still panic in go. Yes, but panics are intended to represent an actually exceptional situation, like dereferencing nil, or the machine running out of memory ... things that normally shouldn't happen, and from which the logic cannot easily recover. > Error handling for an API etc usually make the most sense in a central location ( Which is doable: if err := couldFail(); err != nil { return err } I can let errors bubble up the call stack as far as I want, I just have to be explicit about it.
thombat 4y ago
Please indulge an ignorant question from a Go-curious outsider: are ignored error returns flagged/grumbled-about? One of the enduring PITAs with C-error handling is that AFAIK there's no good way to highlight slipshod code. For example printf() returns "int number_chars_written", system() returns "int status_code": ignoring the first case is ubiquitous and having to cast it to (void) is noisy, ignoring the second is a bad smell and warrants at least a comment. How does this compare to error handling in Go?
- usrbinbash 4y ago
  > are ignored error returns flagged/grumbled-about? No, they are not. func couldFail() error { /*...*/ } func ohNoes() { couldFail() } ohNoes() can call couldFail() and ignore the error return completely, without the compiler complaining. This is intended. Error returns are not special; they are just another return value. Error handling by the caller includes "I don't care if there is an error". Yes, in some situations that's a bad code smell. In others, it really doesn't matter. Go puts the responsibility to decide which applies in the hands of the programmer. To get the same effect in python, I'd have to wrap the call in try: couldFail() except: pass
  - jenny91 4y ago
    I'd hope it's a pretty non-controversial thing by now that software shouldn't silently fail without indicating something's wrong? If I saw the latter Python code in a code review I would squirm. I would scrutinize it very seriously and if there's some really odd case where you really want this, I'd require at least a logger line or a comment to explain why in the world this is desired behavior.
    - usrbinbash 4y ago
      > I'd hope it's a pretty non-controversial thing by now that software shouldn't silently fail without indicating something's wrong? That depends whether the error condition is worth caring about, for a given application, in a given state. eg. how often do programs check if `printf("something")` actually succeeded?
digisign 4y ago
Exceptions propagate up the call stack until caught, simple as that. I prefer this way, but there was one thing I didn't understand until Ned Batchelder taught me, how to layer them: - https://nedbatchelder.com/text/exceptions-in-the-rainforest.html https://nedbatchelder.com/text/exceptions-in-the-rainforest.... - https://nedbatchelder.com/text/exceptions-vs-status.html https://nedbatchelder.com/text/exceptions-vs-status.html I didn't have the full mental model until I read that.

joshuamorton 4y ago

> And even if there is a try-except, I have to check whether except catches the correct TYPE, so now I also need to be aware of the different types of Exceptions bar may raise ... which in turn depends on everything that bar calls, and how bar itself handles these calls, etc. Why? Keep in mind in go, you almost certainly don't check the type of the error. Why hold python to a hire standard (or the opposite: why don't you pass errors with types in golang, and handle errors of only a particular type or set of types?) The answer, in both cases, is of course the same: errors are almost always handled in one of two cases: basically at the callsite (either at the callsite or in the parent function), or they are handled in "main" in some form of catchall. Exceptions are really great for this. You very much don't worry about the things that might be thrown by a child of a child of a child of foo() that you call, because the abstraction shows that you shouldn't care (unless perhaps foo documents explicitly a particular function it throws). You don't need to waste code or mindshare on something you really don't care about. In go however, you do!

usrbinbash 4y ago
> Why? Because unless the caller of foo uses a catchall, it may not actually catch the exception raised by bar. Lets say bar opens a file, and callerOfFoo says `except FileNotFoundError:` ... what if bar opens a file that exists with insufficient Permissions? Then it's `PermissionError`, and callerOfFoo won't catch it. Sure, its possible that callerOfFoo is prepared for that, but my point is, I don't know that unless I check its code.
- joshuamorton 4y ago
  But again, why do you care?
  - dementiapatien 4y ago
    Because I can visualize Go errors completely. They're simple links from one place to another. They are straight fibers connecting my modules and functions to each other. They always work exactly like I expect them to. With python and other exception based languages? I have made hundreds of commits in my lifetime after being surprised that some random 3rd party library throws a nonstandard exception and breaks all sensible control flow that everybody assumed was happening.
    - joshuamorton 4y ago
      This is the reverse of the issue that the parent mentioned though! Consider a go function foo which returns some value and an error. What can you do with that error? You mention control flow being broken by python and others, but the control flow of def myfunc(): if foo(): do_a() else: do_b() and def myfunc(): try: cond = foo() except: raise if cond: do_a() else: do_b() and func myfunc() err { cond, err := foo() if err != nil { return err } if cond { do_a() } else { do_b() } Are all the same! And you can't do anything different in them, because in go, you have no knowledge about the error. Is it aa temp error you should retry? Who knows, are you going to parse the error string to figure it out? The only think you can do in go to an error from some library function is pass the error, possibly adding some additional context, because otherwise you may be mishandling the error. In exception based languages the "pass the error" case is done for you, but if you do want to retry retriable errors, you can actually use a language feature to know that. In go, you have to hope the library creator created an interface (and that all of the possible errors that could percolate up have compatible error-extension interfaces!) that includes some kind of type information, which almost no one does. You're talking about "sensible" control flow, but go doesn't have it!

code_runner 4y ago

Things can still panic in go. Error handling for an API etc usually make the most sense in a central location (some middleware etc) so why would I check that each and every function call was successful. I do like go, but the error handling is hardly the best thing about it. It’s just different. Neither is wrong.

usrbinbash 4y ago
> Things can still panic in go. Yes, but panics are intended to represent an actually exceptional situation, like dereferencing nil, or the machine running out of memory ... things that normally shouldn't happen, and from which the logic cannot easily recover. > Error handling for an API etc usually make the most sense in a central location ( Which is doable: if err := couldFail(); err != nil { return err } I can let errors bubble up the call stack as far as I want, I just have to be explicit about it.

thombat 4y ago

Please indulge an ignorant question from a Go-curious outsider: are ignored error returns flagged/grumbled-about? One of the enduring PITAs with C-error handling is that AFAIK there's no good way to highlight slipshod code. For example printf() returns "int number_chars_written", system() returns "int status_code": ignoring the first case is ubiquitous and having to cast it to (void) is noisy, ignoring the second is a bad smell and warrants at least a comment. How does this compare to error handling in Go?

usrbinbash 4y ago
> are ignored error returns flagged/grumbled-about? No, they are not. func couldFail() error { /*...*/ } func ohNoes() { couldFail() } ohNoes() can call couldFail() and ignore the error return completely, without the compiler complaining. This is intended. Error returns are not special; they are just another return value. Error handling by the caller includes "I don't care if there is an error". Yes, in some situations that's a bad code smell. In others, it really doesn't matter. Go puts the responsibility to decide which applies in the hands of the programmer. To get the same effect in python, I'd have to wrap the call in try: couldFail() except: pass
- jenny91 4y ago
  I'd hope it's a pretty non-controversial thing by now that software shouldn't silently fail without indicating something's wrong? If I saw the latter Python code in a code review I would squirm. I would scrutinize it very seriously and if there's some really odd case where you really want this, I'd require at least a logger line or a comment to explain why in the world this is desired behavior.
  - usrbinbash 4y ago
    > I'd hope it's a pretty non-controversial thing by now that software shouldn't silently fail without indicating something's wrong? That depends whether the error condition is worth caring about, for a given application, in a given state. eg. how often do programs check if `printf("something")` actually succeeded?

digisign 4y ago

Exceptions propagate up the call stack until caught, simple as that. I prefer this way, but there was one thing I didn't understand until Ned Batchelder taught me, how to layer them: - https://nedbatchelder.com/text/exceptions-in-the-rainforest.html https://nedbatchelder.com/text/exceptions-in-the-rainforest.... - https://nedbatchelder.com/text/exceptions-vs-status.html https://nedbatchelder.com/text/exceptions-vs-status.html I didn't have the full mental model until I read that.