Skip to content

Instantly share code, notes, and snippets.

@forstmeier
forstmeier / error_check_suggestions.md
Last active October 18, 2018 23:32
A slight variation on the Go 2 design draft

Personally, I've never really minded the bloat created by the use of the if err != nil { ... }. I've always liked the ability to see right there on the next line exactly what happens in the event of an error.

However, I do understand the eye strain created by many of these popping up in quick succession, particuarlly when calling many helper functions (e.g. anything to do with handling and processing files). In the event that this moves to a full proposal, I would absolutely support the need to continue to allow for the more verbose if err != nil { ... } option, but I wouldn't mind seeing the check/handle desgin be implemented.

One suggestion I would have is to create a bit more clarity at the cost of introducing a few additional characters. I don't really like the idea of when check is triggered it rolls back up through the handle statements - it seems like something that could get confusing when scrolling through longer files.

Maybe something like this could be an option:

func CopyFile

Adrian -

I appreciate that you spent time in writing this post. I know I've been up until 2am writing similarly long ones as well. I will take responsibility for having what is likely an irrational response (I blame Twitter for that) to the term "NoOps", but I invite you to investigate why that might be. I'm certainly not the only one who feels this way, apparently, and thus far have decided this issue is easily the largest distraction in my field I've encountered in recent years. I have had the option to simply ignore my opposition to the term, and just let the chips fall where they may with how popular the term "NoOps" may or may not get. I have obviously not taken that option in the past, but I plan to in the future.

You're not an analyst saying "NoOps". Analysts are easy (for me) to ignore, because they're not practitioners. We have expectations of engineering maturity from practitioners in this field of web engineering, especially those we consider leaders. I don't have any expectations from analysts,