Skip to content

Instantly share code, notes, and snippets.

View atishpatel's full-sized avatar
🙏
Enjoy yourself

Atish Patel atishpatel

🙏
Enjoy yourself
View GitHub Profile
@atishpatel
atishpatel / errorHandlingFeedback.md
Last active August 30, 2018 01:09
Not adding detail to error handling is inelegant

It seems the current proposal for error handling will lead to poor practice in error handling.

There are 3 ways errors are usually handled:

  1. if err != nil { return err }
  2. if err != nil { log.Printf("failed to x: %+v", err) return err }
  3. if err != nil { return errors.Wrapf(err, "failed to x: ")}

The check err and handle err approch takes care of the first approch but fails to address 2 and 3 because there is no means to add detail to the error. This means if you have an error that's handled from the new approch in a long function, there is no way to know which check caused the error. So, the error less detailed and the code is harder to debug.

One way to address this is to add more parameters to check and handle.