Hacker News new | past | comments | ask | show | jobs | submit login

Ahh, errors. A programmer's best friend or enemy or both? I may be a rookie, but I'll say this:

- A few years ago I chose to learn Python "The Hard Way"[1] because I already had experience with scripting and a little bit of C++/Java/PHP/Js. While I fell in love with the flexibility of the language — how idiosyncratic it could be made, how quickly fluency came — error handling remained a mysterious dark space to me, a "TODO" for later. [which I didn't because I didn't program much after this first real training]

- I later tried to become "Eloquent" in Javascript[2], and while I can never praise that book enough, the language's paradigm wasn't what made error handling 'click' for me. Now I see, but it took a trip far, far away. [Js isn't my problem space, and when it is I'd rather use TypeScript probably]

- And finally Go. While I haven't finished once "The Go Programming Language"[3] yet — just followed a few great online books/courses so far (notably by Jon Calhoun[4], Xoogler), and only built a few basic things — I can say this: now I get it. I mean errors. I really do.

I think these few points mattered:

- Go has error checking 'in your face' indeed and makes it useful, because passing a value makes sense, and error type is no longer abstracted as in more OOP paradigms, it doesn't feel "otherworldly" to the present code, it's right there in the imperative flow.

- Testing is well-integrated (`_test.go` files; I know, at a basic level, but that's what I expect from a 'standard' tooling). Because it's a core feature and quite easy, you tend to use it; and testing helps thinking (conceptualizing) of a 'meta' framework around error handling. As a Go programmer you quickly understand that it's clearly, totally up to you to define this "otherworldly" space where your code exits its normal 'world'.

I find it hard to phrase it for now, but I'm positive Go's implementation of errors (essentially forcing you to go through it) made me level up big time. You clearly see the "normal execution space" and the "erronous space", and how design helps you keep your code either well within the former, or graciously through the latter. It feels incredibly safe, especially as a newbie.

Also, emmet snippets. Makes writing fast, but seeing the `if err != nil { return ... }` blocks is extremely beneficial to reading code, which is what we do most, by far.

Also, people don't mention these much but things like `panic()` and `recover()`[5] help you think of and learn about your own problem in elementary terms, first principles — do we need to halt execution or can we recover from this? It's all part of a sane and safe executive thread, or so it feels.

I don't know if I'll be programming Go at my job 5 years from now, I really don't; but I'll always have Go to thank for making me understand much in programming first principles.

[1]: https://www.goodreads.com/book/show/15858137-learn-python-th...

[2]: https://www.goodreads.com/book/show/39866497-eloquent-javasc...

[3]: https://www.goodreads.com/book/show/25080953-the-go-programm...

[4]: https://www.calhoun.io/

[5]: https://blog.golang.org/defer-panic-and-recover






Best error handling is Either aka Maybe aka Result.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: