12 ms·
Don't just check errors, handle them gracefully (2016)
- datadrivenangel 1y agoSoftware should fall over quickly. Graceful error handling can hide many issues.
- markwaldron 1y agoMy take on this post is that things will break, but they should tell you they broke in an actionable and somewhat standardized way. If the only message that shows up is "An error has occured" that doesn't help the user, especially if they are non-technical.
- avg_dev 1y agohttps://go.dev/blog/go1.13-errors https://go.dev/blog/go1.13-errors I wouldn't use the advice in this article. It's quite old and the stdlib now has support for new stuff via error wrapping.
- anttiharju 1y agoPosted this because of the other Go error handling post today https://news.ycombinator.com/item?id=44171677 https://news.ycombinator.com/item?id=44171677 I like error wrapping. I've worked in codebases where systems had to be debugged by piecing together individual log lines. With error wrapping I can usually see the exact path that lead to the error in one line.
- glenjamin 1y agoIt would be cool if someone could come up with a way for the runtime system to automatically wrap errors with the calling context. That way you’d be able to trace the stack of functions that were involved in passing an error back up to the place where it’s actually handled.
- danesparza 1y ago"With error wrapping I can usually see the exact path that lead to the error in one line" This is called a stack trace, and I agree it can be very useful (if the developers were thoughtful about their error handling)
- anttiharju 1y agoI suppose I phrased this poorly. Stack traces are useful indeed. I guess what I like that usually wrapped errors are bit more thoughtful, stack traces can look a bit like "vomit".
- RSHEPP 1y agofrom my experience of late, engineers usually toss stack traces into LLMs and ask what the issue is. good error wrapping, engineers grep for one of the first errors and get to the error code right away. both ways work.
- sfn42 1y agoIf you can't read a stack trace without an LLM you're not an engineer.
- danesparza 1y agoCounterpoint: You might also just be working on an exceptionally bad codebase or with an exceptionally bad runtime (I'm looking at you C/C++ or minified Javascript)
- sfn42 1y agoSure, if the stack trace doesn't have any useful information then it's not useful. In my experience it's usually useful though, it usually tells you both what the problem is and where it is. Sadly a lot of people just don't even try to read them.
- eschatology 1y ago
- 3cats-in-a-coat 1y ago"Handling errors gracefully" doesn't happen at the handler. It starts at the execution model and your architecture. If a component can "bomb" in an isolated way, then the client that invoked that component can handle that gracefully. This means things like durability, consistency, atomicity, and isolated side-effects (if any). This is what Erlang does. A process is isolated, so when it just falls apart, the parent can handle that "gracefully" despite said process literally disintegrated in a critical irreparable way. It's a bit like designing covert spy networks...
- ninetyninenine 1y agoI love the go philosophy of errors being silent by default. It forces us developers to handle things gracefully. Additionally no stack traces along with the errors which is good because devs are too reliant on stack traces nowadays.
- altruios 1y agoThis sounds like it needs an /s. The complaint of developers "being reliant on stack traces" tone sounds an awful lot like: "real programmers just use punch cards and ignore any tooling we've come up with in the last 70 years: just use your brain"
- ninetyninenine 1y agoIt’s not sarcasm. This is just my personal philosophy. I feel attacked.
- altruios 1y agoI speak in hyperbole here. I only point out the giants whos shoulders we stand on left us fantastic tools to use. There is something to the philosophy of keeping your interface 'dark' such that you learn to 'shine'. But that's something I ascribe to a personal development journey.
- pixelpoet 1y agoI like my Go proverbs to be at least 100 years old: https://en.wikipedia.org/wiki/Go_proverb https://en.wikipedia.org/wiki/Go_proverb
- vel0city 1y agoGotta love reading a new to you codebase and seeing a bunch of catch (Exception ex) { }; littered throughout. Fixed the bug boss, close that ticket!
- marklubi 1y agoTotally agree with finding the source of the bug (there are some that I've spent weeks tracking down, there are millions of people that have my fixed code on their devices). If you've going to catch an error with a noop, there better be a comment explaining why you're not doing anything. It's not often, but sometimes, failing gracefully is just swallowing the error and moving on.
- xboxnolifes 1y agoAt minimum, the error should be logged somewhere, and not just vanished. At least you get to know how frequently it occurs if/when that becomes meaningful to you.
- vel0city 1y agoExactly this. Log it, maybe at some really verbose log level, but please let me know it is hitting this point and a little bit of information of what the exception was. Also, only do it for exceptions you think might actually hit there and you're OK with quietly squashing. Otherwise, please let something else try and handle it.
- marklubi 1y agoIn an app, if you have a string of network requests to your own services, there's no particular point in logging multiple (or any) 'no internet connection' errors. They won't make it to you, and having those doesn't provide much value. That's an end user problem. I have plenty of monitors to ensure my services are available (four-nines uptime for almost a decade). Internet unavailable errors are useless to log.
- scrame 1y agothis completely happened to me, but with a comment: // this never happens ... guess what happened? /happenings
- carlio 1y ago"Something went wrong. Please try again".
- 827a 1y agoFor a language that prides itself on its error handling, that's a whole lot of words written on the myriad of incorrect and bad ways to handle errors in the language, many of which are actively and irreversibly deployed in the standard library.
- neuroelectron 1y agoBest way to handle errors is to exit
- rollulus 1y agoThis was a great article back then but Go’s errors package has changed since then quite a bit, with e.g. Is, As, and fmt.Errorf’s %w.
- Glittergorp 1y ago[dead]
- Entwickler 1y agoYeah, this has some general high level good advice, but is so old it doesn't include the new idiomatic ways of using errors.Is and error wrapping for error checking...
- deleted 1y ago[deleted]