4 ms·

go is step by step reinventing exceptions

wwarner 3y ago
go basically has exceptions with panic & recover. and it’s perfectly simple to add stack traces to errors, should you want it.
- lsaferite 3y ago
  That completely misses the fact that you need the providers of the code several layers away from you to make those choices and they frequently don't. I can add stack traces and raise panics all day long in my code and it will never help me trace a deep error in my system. The collective blindness to that in the go world is staggering.
alphazard 3y ago
Exceptions typically unwind the stack, producing a stack trace similar to what certain Go error types already do. Go's panic does actually unwind the stack. In a sense, Go has had Java/Python style exceptions, from the beginning, through panic and recover. This project distinguishes itself from that pattern in the README. As far as error handling is concerned, errors as values is the modern thinking. Go is not behind the times here. If you squint, the `(T, error)` return type is very similar to Rust's `Result`, and the `if err != nil` idiom is basically Monadic control flow.
- tialaramex 3y ago
  > If you squint, the `(T, error)` return type is very similar to Rust's `Result` This requires the kind of squinting where 9 x 9 = 81 is basically the same as 9 + 9 = 18 right? I mean, they're roughly the same symbols, albeit one at slightly different angle, and in a different order... Result is a sum type, as are a lot of key things in Rust. Take the Rust type Result<bool,()> - this has three possible values, Ok(true), Ok(false), Err. The analogous Go product type has four possible values, (false,false) (false, true), (true, false) and (true, true).
  - bensecure 3y ago
    the go type has the implicit restriction that if error is true, then the result is meaningless. So really it has 3 meaningfully distinct values.
    - randomdata 3y ago
      That depends on perspective. An idiomatic Go function will ensure that T is always useful, regardless of the error state. At very least it will return the zero value for T, to which the Go maxim states: Make the zero value useful. From the perspective of writing the function returning (T, error), there will always be four states, with T and error being independent of each other. Anything else is faulty design. Unfortunately, some early Go code written before things were well understood left T to be undefined given certain error states, so one cannot assume that T will be valid in all cases for all functions. This does mean that the caller's perspective can only reliably consider three states absent of diving deeper (e.g. reading the documentation).
    - lsaferite 3y ago
      > implicit restriction that if error is true, then the result is meaningless By 'implicit' I assume you mean 'by convention'? I say this because unless I've misread the go spec (and that's a distinct possibility), function returns are either a single value or a tuple and there is no specification on tuple returns and mutually exclusive values. FWIW, I mostly like go and work with it practically every day. I absolutely loathe it's ideas on error handling. I have quite strong feelings on the subject that aren't fit for polite discussion.
      - deleted 3y ago
        [deleted]
      - randomdata 3y ago
        > I absolutely loathe it's ideas on error handling. Its idea is simply that error is just state like any other. I find that to be quite reasonable – and something I miss dearly when I work in other languages which try to get overly fancy to try and hide that fact. There is nothing special about errors. The machine certainly has no concept of errors. Why does it need special constructs? Bad practices like assuming T and error are dependent do break the ideas, but a language can only hold the hands of poor developers so much. Someone determined enough to write bad code will do so in any language. Realistically, if there is a handling problem, it is a problem for all values of all kinds. Every single problem one can point to about handling errors is also a problem when handing names, email addresses, random numbers, etc. To single it out as an error handling problem specifically is flawed. > I have quite strong feelings on the subject that aren't fit for polite discussion. I'd love to hear more. You won't hurt my feelings. Getting worked up about a programming language discussion is illogical.
deleted 3y ago
[deleted]

go basically has exceptions with panic & recover. and it’s perfectly simple to add stack traces to errors, should you want it.

lsaferite 3y ago
That completely misses the fact that you need the providers of the code several layers away from you to make those choices and they frequently don't. I can add stack traces and raise panics all day long in my code and it will never help me trace a deep error in my system. The collective blindness to that in the go world is staggering.

alphazard 3y ago

Exceptions typically unwind the stack, producing a stack trace similar to what certain Go error types already do. Go's panic does actually unwind the stack. In a sense, Go has had Java/Python style exceptions, from the beginning, through panic and recover. This project distinguishes itself from that pattern in the README. As far as error handling is concerned, errors as values is the modern thinking. Go is not behind the times here. If you squint, the `(T, error)` return type is very similar to Rust's `Result`, and the `if err != nil` idiom is basically Monadic control flow.

tialaramex 3y ago
> If you squint, the `(T, error)` return type is very similar to Rust's `Result` This requires the kind of squinting where 9 x 9 = 81 is basically the same as 9 + 9 = 18 right? I mean, they're roughly the same symbols, albeit one at slightly different angle, and in a different order... Result is a sum type, as are a lot of key things in Rust. Take the Rust type Result<bool,()> - this has three possible values, Ok(true), Ok(false), Err. The analogous Go product type has four possible values, (false,false) (false, true), (true, false) and (true, true).
- bensecure 3y ago
  the go type has the implicit restriction that if error is true, then the result is meaningless. So really it has 3 meaningfully distinct values.
  - randomdata 3y ago
    That depends on perspective. An idiomatic Go function will ensure that T is always useful, regardless of the error state. At very least it will return the zero value for T, to which the Go maxim states: Make the zero value useful. From the perspective of writing the function returning (T, error), there will always be four states, with T and error being independent of each other. Anything else is faulty design. Unfortunately, some early Go code written before things were well understood left T to be undefined given certain error states, so one cannot assume that T will be valid in all cases for all functions. This does mean that the caller's perspective can only reliably consider three states absent of diving deeper (e.g. reading the documentation).
  - lsaferite 3y ago
    > implicit restriction that if error is true, then the result is meaningless By 'implicit' I assume you mean 'by convention'? I say this because unless I've misread the go spec (and that's a distinct possibility), function returns are either a single value or a tuple and there is no specification on tuple returns and mutually exclusive values. FWIW, I mostly like go and work with it practically every day. I absolutely loathe it's ideas on error handling. I have quite strong feelings on the subject that aren't fit for polite discussion.
    - deleted 3y ago
      [deleted]
    - randomdata 3y ago
      > I absolutely loathe it's ideas on error handling. Its idea is simply that error is just state like any other. I find that to be quite reasonable – and something I miss dearly when I work in other languages which try to get overly fancy to try and hide that fact. There is nothing special about errors. The machine certainly has no concept of errors. Why does it need special constructs? Bad practices like assuming T and error are dependent do break the ideas, but a language can only hold the hands of poor developers so much. Someone determined enough to write bad code will do so in any language. Realistically, if there is a handling problem, it is a problem for all values of all kinds. Every single problem one can point to about handling errors is also a problem when handing names, email addresses, random numbers, etc. To single it out as an error handling problem specifically is flawed. > I have quite strong feelings on the subject that aren't fit for polite discussion. I'd love to hear more. You won't hurt my feelings. Getting worked up about a programming language discussion is illogical.

deleted 3y ago

[deleted]