3 ms·

> 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 Exception

> 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!
      - dementiapatien 4y ago
        I argue that errors.Wrap and errors.Is from the Go stdlib solves this problem. Libraries can export their own error types and you can check if they threw that error type. I use this pattern all the time to handle special errors differently. Used it to implement optimistic locking which does ~not~ simply propagate all errors upwards! https://gosamples.dev/check-error-type/ https://gosamples.dev/check-error-type/ cond, err := foo() if errors.Is(err, ErrFooHadTemporaryFailure) { // retry } else if errors.Is(err, ErrFooHostOffline) { // switchFooHost() } else if err != nil { // propagate unhandled error upwards return nil, fmt.Errorf("foo unhandled err: %w", err) } Of course it is up to the package author (or yourself) to write functions that return specific wrapped error types. Otherwise we're stuck in the situation your comment describes. What do you mean by creating an error interface? It's a one liner to make a new error case: var ErrFooHadTemporaryFailure = errors.New("temporarily failure, retry later")

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!
    - dementiapatien 4y ago
      I argue that errors.Wrap and errors.Is from the Go stdlib solves this problem. Libraries can export their own error types and you can check if they threw that error type. I use this pattern all the time to handle special errors differently. Used it to implement optimistic locking which does ~not~ simply propagate all errors upwards! https://gosamples.dev/check-error-type/ https://gosamples.dev/check-error-type/ cond, err := foo() if errors.Is(err, ErrFooHadTemporaryFailure) { // retry } else if errors.Is(err, ErrFooHostOffline) { // switchFooHost() } else if err != nil { // propagate unhandled error upwards return nil, fmt.Errorf("foo unhandled err: %w", err) } Of course it is up to the package author (or yourself) to write functions that return specific wrapped error types. Otherwise we're stuck in the situation your comment describes. What do you mean by creating an error interface? It's a one liner to make a new error case: var ErrFooHadTemporaryFailure = errors.New("temporarily failure, retry later")