5 ms·
It's not 75% of the code-base. During the error handling proposals, the Go team analyzed a large corpus of Go, and it turns out people drastically overstate how
by icholy 3y ago
It's not 75% of the code-base. During the error handling proposals, the Go team analyzed a large corpus of Go, and it turns out people drastically overstate how much error handling contributes to the line count.
- jahewson 3y agoIt does make me wonder if the fact that people feel this way says something about how much cognitive effort is consumed by error handling and that it might be disproportionate.
- t-3 3y agoError handling is something you always need to think about for serious code, but often feels like unnecessary work and boilerplate for exploratory programming or simple hacks.
- cowl 3y agonot 75% of all code but 75 of all code that is doing anything with meaningful practically. the classic example of a simple copyFile func. func CopyFile(src, dst string) error { r, err := os.Open(src) if err != nil { return err } defer r.Close() w, err := os.Create(dst) if err != nil { return err } defer w.Close() if _, err := io.Copy(w, r); err != nil { return err } if err := w.Close(); err != nil { return err } }
- no_wizard 3y agocould you in theory break this into other functions or no? You could have smaller discrete functions that abstract the handling of each action a little bit and be more reusable, or is that not possible in Go
- ikari_pl 3y agolike Open, Copy...? These shorter functions need to signal their failure somehow, so calling them looks exactly like the example.
- xarope 3y agoYou could almost shorten it to: if r, err := os.Open(src); err != nil { return err } defer r.Close() But then r is not in scope for the r.Close proper