Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gopher Wrangling: Effective error handling in Go

stephenn.com

Post reply on HN
Print view View original

201–210 of 310 posts

Re: Gopher Wrangling: Effective error handling in Go

#201

Post by masklinn »

randomdata wrote: post #79
kadoban wrote: post #69

Earlier quoted context omitted.

This doesn't really make much sense. The producer knows what it's returning. In the _vastly_ common case, it's either returning an error or a success object, but the Go type system is unable to represent that. The caller trying to pretend that the success object is there isn't a freedom the caller gets in the current system, it's an artifact of the type system not being powerful enough to encode the situation accurat…

> The producer knows what it's returning. But doesn't know how the return values will be used by the caller. What is perhaps lost in this is where Go says that values should always be useful? > If you have a function that can return both an object and an error, there still should be a way to represent that (exactly the current way). Exactly the current way is what is said to be deficient, though. A function of this t…

> A function of this type is naturally going to return a file every time because a file is always useful, even when there is failure.

You might want to look at what Go does with zero-valued File. At best it ignores them and returns an error, at worst it panics.

There is no situation where a zero-valued file is useful.

Re: Gopher Wrangling: Effective error handling in Go

#202

Post by kaba0 »

lanstin wrote: post #45
preseinger wrote: post #30

Earlier quoted context omitted.

if you write a line of code that can fail, then you should deal with the possibility of that line failing there, directly, in-line _how_ you deal with that failure is a separate question but it's critical that every fallible expression explicitly and visibly demonstrates the possibility of failure this is in no way an "error handling mess" -- on the contrary, it is basically the only way to produce robust and reliabl…

i wish people understood this thinking about and handling all errors, as a prime functiom of the code, is why things like Linux and C Python and X server and git and so on are so reliable.

The only reasons those are reliable is that they have millions of hours of runtime, so that the easier bugs have all been fixed now.

If anything, they have become successful in spite of C.

Re: Gopher Wrangling: Effective error handling in Go

#203

Post by adezxc »

kaba0 wrote: post #191
adezxc wrote: post #175

Earlier quoted context omitted.

It is frustrating to read Java code. I don't want to understand your abstractions or class definitions like final, static and whatever. I don't want to learn about Gradle or Maven to understand how a package is working, I'd rather do it in code. Consider even the current "Hello, world" example in Java (Yes, I know about the proposal about simplifying it), it is tedious, why would I need to understand public/private a…

There is no going around abstraction, that’s a necessary part of any non-trivial program as that’s the only method we have to control complexity. Your struct is also an abstraction, you could have defined another one, use it differently, etc. Many of the design patterns are useless bullshit, that is long superseded by a language feature, so that point doesn’t stand imo. Go also has public/protected, it is just case-s…

It is easier to know that lowercase is package-specific, uppercase is exported, than knowing which field is private/public by default.

Go reserved keywords: break, default, func, interface, select, case, defer, go, map, struct, chan, else, goto, package, switch, const, fallthrough, if, range, type, continue, for, import, return, var

Java reserved keywords: abstract, continue, for, new, switch, assert, default, goto*, package, synchronized, boolean, do, if, private, this, break, double, implements, protected, throw, byte, else, import, public, throws, case, enum, instanceof, return, transient, catch, extends, int, short, try, char, final, interface, static, void, class, finally, long, strictfp, volatile, const, float, native, super, while.

Re: Gopher Wrangling: Effective error handling in Go

#204

Post by sethammons »

adezxc wrote: post #175
za3faran wrote: post #142

Earlier quoted context omitted.

Could you elaborate on exactly what complexity in Java you're referring to? By having an overly simplistic language, you end up pushing more complexity onto the programmer and into the code base. There is no free lunch. I find it much more sane to solve and express code in Java. You get terser, more to the point code that reflects the underlying logic more clearly, compared to having to read many lines or pages to un…

It is frustrating to read Java code. I don't want to understand your abstractions or class definitions like final, static and whatever. I don't want to learn about Gradle or Maven to understand how a package is working, I'd rather do it in code. Consider even the current "Hello, world" example in Java (Yes, I know about the proposal about simplifying it), it is tedious, why would I need to understand public/private a…

A number of years ago, I decided to try out this Java monster. Figured I'd add it to the tool belt. Opened the first hello world tutorial Google game me. It started with xml files to define string content. I noped out.

Re: Gopher Wrangling: Effective error handling in Go

#205

Post by flippinburgers »

Man I definitely handle errors the "wrong way" in almost all go code I have written. I take a "log immediately with filename and line number" approach. For me, it works. For teams maybe not. For large codebases with a bunch of 'I am a "programmer" (because it makes me loads of cash) individuals', it is definitely not a good idea. It requires discipline. Personally I hate stack traces.

Re: Gopher Wrangling: Effective error handling in Go

#206

Post by sethammons »

AlexCoventry wrote: post #31
marcus_holmes wrote: post #22

Surprised that the "always wrap your errors" rule isn't in there. It's been the rule in the last few Go teams I've been in.

We moved away from wrapping them recently for performance reasons.

You got to add more context here. An entire blog post would be worthy. We do some very performant code at high scale and error wrapping has never put pressure on our systems. Highly interested in what you saw.

Re: Gopher Wrangling: Effective error handling in Go

#207

Post by janosdebugs »

konart wrote: post #144
janosd wrote: post #116

Go's error handling is a horrible mess: 1. It's easy to ignore returned errors without any compiler warnings. You have to rely on third party tools such as golangci-lint to report missing error handling. 2. Errors don't carry stack traces with them, you have to rely on third party libraries or custom errors to get that functionality and you will only get it for your own code, not in other libraries you are using. 3.…

>3. It's unclear who should add context to error messages is it the caller or callee? Usually it gets skipped, leading to useless error messages Why is that unclear? Let's say you are writting a db client package and a service around it. The package's db.Exec(query) method should return and error that will have an error text received from db if any AND\OR context from the package itself. Then in your service you add…

>> 6

> Not sure about "most" loggers, but I have no problem with zap. Popular, definetelly can be injected etc.

That may be so, but a lot of libraries use a logger that isn't zap and isn't injectable, or the library doesn't expose a way to inject a logger even if the logger itself supports it. Plus, if you have 3 dependencies, you'll end up with 4 different logging libraries you need to worry about. In the end, you end up having a mess around logging unless you only rely on your own code and don't use libraries.

(Should have phrased the parent better.)

Re: Gopher Wrangling: Effective error handling in Go

#208

Post by janosdebugs »

nbraxf100 wrote: post #176
janosd wrote: post #116

Go's error handling is a horrible mess: 1. It's easy to ignore returned errors without any compiler warnings. You have to rely on third party tools such as golangci-lint to report missing error handling. 2. Errors don't carry stack traces with them, you have to rely on third party libraries or custom errors to get that functionality and you will only get it for your own code, not in other libraries you are using. 3.…

The error handling is second nature to anyone who has done C or Unix programming. It just feels dirty not to check for an an error. This is one part I like about Go.

Unfortunately, at scale a feeling of dirtiness doesn't prevent a lot of really bad code from being written. Looking across the Go landscape, inadequate error handling is present in almost all projects I come across.

Re: Gopher Wrangling: Effective error handling in Go

#209

Post by appleflaxen »

janosd wrote: post #116

Go's error handling is a horrible mess: 1. It's easy to ignore returned errors without any compiler warnings. You have to rely on third party tools such as golangci-lint to report missing error handling. 2. Errors don't carry stack traces with them, you have to rely on third party libraries or custom errors to get that functionality and you will only get it for your own code, not in other libraries you are using. 3.…

It sounds like you think about error handling a lot.

Is there a language that has error handling "done well " that you like?

Re: Gopher Wrangling: Effective error handling in Go

#210

Post by janosd »

notTooFarGone wrote: post #121
janosd wrote: post #116

Go's error handling is a horrible mess: 1. It's easy to ignore returned errors without any compiler warnings. You have to rely on third party tools such as golangci-lint to report missing error handling. 2. Errors don't carry stack traces with them, you have to rely on third party libraries or custom errors to get that functionality and you will only get it for your own code, not in other libraries you are using. 3.…

Calling a linter thirdparty in Go is really disingenuous. Like you install go in your favourite IDE and it's batteries included. It's part of the standard set.

Go is a weird mix. It doesn't even let you create an unused variables, but happily lets you ignore errors or return variables. That makes no sense and is on Go, not on the admittedly quite excellent tooling provided by people who are not the Go dev team (third party). An IDE is just as much third party to the language as golangci-lint is.
Post reply on HN