4 ms·
Just when you think you have The Best Way of handling errors in Go figured out, they add yet another paradigm. Is a shared err type package on the way out? I
by candiddevmike 4y ago
Just when you think you have The Best Way of handling errors in Go figured out, they add yet another paradigm.
Is a shared err type package on the way out? I use it to bubble up HTTP status codes consistently, is there a better way? Should you always use sentinel errors?
- metadat 4y agoThe only constant is change. Especially with Go, apparently. It's hard to evaluate the comparison of Golang of today to the one I originally discovered 11 years ago in 2012. Then, it was a breath of fresh air. Nowadays.. I find myself sighing. It works but the joy has faded. Bit rot is life.
- mixedCase 4y agoThe joys and woes of reinventing computer programming right where it was left off in the early 70s.
- kubb 4y agoI think I can sympathise, it's hard to keep up with all the development in PL, so it's easy to convince yourself that all those new inventions are stupid anyway and you don't need them, you'll do it your way. And then, slowly over a couple of decades, other people will be making it their life's work to add in the things that you thought were stupid because inevitably the need for them surfaces.
- groestl 4y agoOr you've seen an approach fail spectacularly in a programming language you're familiar with, which causes you to throw out the baby with the bath water.
- metadat 4y agoAny specific examples you can share?
- groestl 4y agoA bit tongue in cheek, but I'm just referring to Rob Pike et al., exceptions, and C++. And I must clarify that by "fail spectacularly" I mean solely from the POV of the aspiring language designer, not necessarily from other language users. People enjoy C++ exceptions now, it seems, in combination with RAII, but back then it was probably a different story.
- wrycoder 4y agoImplementors gotta implement, no?
- zdragnar 4y agoHow many languages go through the first 11 years of life without significant changes? There are lisps, which have no syntax to change, and I guess elixir, which is itself just a syntax for a very mature runtime (BEAM). Hell, even C underwent pretty major changes from 72 onwards, because every compiler supported entirely different features. Things like void functions and returning structs or unions. Granted, this predated internet distribution of software, so changes overall were perhaps slower within a single implementation, but there were still radical developments happening on a frequent basis.
- kaba0 4y ago> How many languages go through the first 11 years of life without significant changes Only if a language with basically zero new concepts could have just learned from the litany of other managed languages’ mistakes..
- philosopher1234 4y agoCan you give an example of a feature where the designers of go failed to consider other languages mistakes? Every discussion of there’s I’ve read has been thoughtful, open, and well cited.
- lakomen 4y agoYeah I'm not using generics and they're a big turn off. If Rust wasn't so ugly and the JVM so Swiss-cheesy and stuck in paradigms, I would switch. So I keep writing my old ways code in Go and act like the new features don't exist. Big sigh
- earthboundkid 4y agoIt’s the same paradigm. You still have to do if err != nil. Multierrors have been in the community forever. It’s just been added to the standard library is all.
- deleted 4y ago[deleted]
- Groxx 4y agoWell. Kinda. Except that now if someone does `errors.Join` and they pass it to existing code that was using `errors.Unwrap` to inspect an error chain... ... they now get a not-unwrap-able error. Which they can still `As` to inspect... ...but since it's a tree, they can't recursively-`As` to find all instances of a type of error in a chain, like they could before (if you find something in one branch, you can only traverse that branch, because As doesn't maintain iteration-state). It's not an unambiguous win, sadly. New code interacting with old code might misbehave.
- earthboundkid 4y agoWhy would the other code be manually unwrapping and then doing an As test instead of using errors.As? That's extremely Hyram's Law behavior. :-) I agree though that if you have an error log reporting system it should be updated to understand the new multierrors. OTOH, if it's not, it will just see the multierrors as a single node and work fine otherwise.
- Groxx 4y agoAnything trying to display the whole chain is one example, like some every logging library or custom output in existence. For behavior: sometimes wrapping order matters, and As is convoluted to use to determine that, to say the least. Manually unwrapping is easy, and reasonably safe and easy - the standard library does it! But...
- andrewstuart2 4y agoSentinel errors are only one way, and definitely not the best way imo. `errors.As` gets you the ability to recursively and multierror-safely check to see if somewhere in the stack, an error of a certain type is found, and access its extra data, to determine e.g. which status code is most appropriate based on any extra data in that type. I think shared types from a package make a ton of sense and are really practical for writing flexible and maintainable code.
- tptacek 4y agoThis is the same way of handling errors Go has always had. The point of Go errors is that they're just values; you program them like you would anything else. People have had multi-error packages for years, and Go encouraged it. Now there's a standard one.
- threeseed 4y ago[flagged]
- badrequest 4y agoEvery time this completely tired and worn out take is regurgitated on this website, it reminds me that people write big fat try/catch blocks because they never expect things like file reads to fail.
- Groxx 4y agoThough at least Java people doing that get a stack trace, so they can find out which attempt failed. In random Go code you're fairly likely to get "error: file not found" and literally no other info.
- Joker_vD 4y agoWell, the Go's FileNotFound errors returned from the standard library do have the file name in the message string. Java's FileNotFoundException exceptions, on the other hand, don't; and the stacktrace is usually useless because it doesn't record the values of the local variable anyhow.
- Groxx 4y agoyeah, the inconsistency there in both standard libraries is... strange to say the least. more info is more gooder IMO, the runtime cost is SO much lower than the troubleshooting cost.
- 4y ago
- gregwebs 4y agoI wrote a package to attach codes to errors via wrapping rather than a shared error type: https://github.com/gregwebs/errcode https://github.com/gregwebs/errcode
- revskill 4y agoNo, Go programmers are get paid to get if err != nil done correctly.