5 ms·

If you browse random Go code from https://pkg.go.dev/ https://pkg.go.dev/ you will have a hard time finding that hypothetical case where most of your code is er

If you browse random Go code from https://pkg.go.dev/ https://pkg.go.dev/ you will have a hard time finding that hypothetical case where most of your code is error handling chores. The problem is artificial.

otabdeveloper4 3y ago
Yes, I agree. If you just ignore errors, they will go away. #yolo P.S. That said, any program written in Go is an absolute shitshow of crappy UX because of the (inevitably) inconsistent and often incorrect error handling.
- rollulus 3y ago
  With a statement like that in your postscript I think it would be fair to elaborate.
  - otabdeveloper4 3y ago
    Once a Go program goes off the happy path, the only way to figure out what happened is to read the source code. (No, you cannot have a stack trace. Stack traces make junior programmers feel uncomfortable, and so Google made them verboten.) And even then, because Go uses insane and outdated OOP practices like casting all pointers to a generic base class, even reading the source code is a exercise in frustration and rage.
    - rollulus 3y ago
      There’s error wrapping for adding context. Where one adds a human readable context to errors. Stack traces as I know them from the JVM world, with their line numbers and method names, seem a lot more coupled to the source code, so I’d say it’s the other way around really.
      - otabdeveloper4 3y ago
        I speak as a user of programs written in Go. (By junior programmers who love ""simple"" programming languages.) Thank God I don't have to code anything in Go myself.
    - pkolaczk 3y ago
      Stacktraces are not useful for end users of the program and should never be shown unless there is a bug in the program. It is silly how many Java or Python programs display stacktraces on trivially preventable problems that are not bugs (e.g. file not found) instead of giving short human readable messages.
      - otabdeveloper4 3y ago
        Yeah, it's a good thing that programs never have bugs.
        pkolaczk 3y ago
        I'm not taking about bugs but error handling. For bugs there are panics and they do print stacktraces. For error handling stacktraces are just noise.
closeparen 3y ago
Library code, especially stdlib, is usually the bottom of the abstraction chain and rarely performs fallible operations like IO. It’s the one originating the errors. The issue is that application code usually has several layers between the end-user and the fundamental operations like Read()/Write(). Bookkeeping errors through all these layers is a chore. You can skip the layers but then you get spaghetti.

otabdeveloper4 3y ago

Yes, I agree. If you just ignore errors, they will go away. #yolo P.S. That said, any program written in Go is an absolute shitshow of crappy UX because of the (inevitably) inconsistent and often incorrect error handling.

rollulus 3y ago
With a statement like that in your postscript I think it would be fair to elaborate.
- otabdeveloper4 3y ago
  Once a Go program goes off the happy path, the only way to figure out what happened is to read the source code. (No, you cannot have a stack trace. Stack traces make junior programmers feel uncomfortable, and so Google made them verboten.) And even then, because Go uses insane and outdated OOP practices like casting all pointers to a generic base class, even reading the source code is a exercise in frustration and rage.
  - rollulus 3y ago
    There’s error wrapping for adding context. Where one adds a human readable context to errors. Stack traces as I know them from the JVM world, with their line numbers and method names, seem a lot more coupled to the source code, so I’d say it’s the other way around really.
    - otabdeveloper4 3y ago
      I speak as a user of programs written in Go. (By junior programmers who love ""simple"" programming languages.) Thank God I don't have to code anything in Go myself.
  - pkolaczk 3y ago
    Stacktraces are not useful for end users of the program and should never be shown unless there is a bug in the program. It is silly how many Java or Python programs display stacktraces on trivially preventable problems that are not bugs (e.g. file not found) instead of giving short human readable messages.
    - otabdeveloper4 3y ago
      Yeah, it's a good thing that programs never have bugs.
      - pkolaczk 3y ago
        I'm not taking about bugs but error handling. For bugs there are panics and they do print stacktraces. For error handling stacktraces are just noise.

closeparen 3y ago

Library code, especially stdlib, is usually the bottom of the abstraction chain and rarely performs fallible operations like IO. It’s the one originating the errors. The issue is that application code usually has several layers between the end-user and the fundamental operations like Read()/Write(). Bookkeeping errors through all these layers is a chore. You can skip the layers but then you get spaghetti.