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

191–200 of 310 posts

Re: Gopher Wrangling: Effective error handling in Go

#191

Post by kaba0 »

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…

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-specific. If anything, that makes it harder to understand, how should I knew that Asd is different from asd beforehand?

Re: Gopher Wrangling: Effective error handling in Go

#192

Post by [deleted] »

kodah wrote: post #123
andrewjf wrote: post #101

Earlier quoted context omitted.

I feel like a lot, if not all, has to do with the Google backing. Back when Go was announced, the company had _a lot_ of goodwill, and were envied by anyone doing software engineering. So, pretty much anything they did had an immediate following and base of engineers willing to blindly adopt whatever they did.

Hard disagree. Go provided a simple answer for asynchronousness in 2012 and was used to build Kubernetes. Because it was used to build Kubernetes a lot of patterns and influence developed very quickly, which made the language very agreeable to anyone writing APIs, systems tooling, or daemons. The portability and cross compilation were also developer favorites as they have downline effects in how simple it is to produ…

[deleted]

Re: Gopher Wrangling: Effective error handling in Go

#193

Post by kaba0 »

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.

An if err with some random one-liner in the err part is not error handling.

You can’t reasonably handle an error condition on a local basis, that’s why exceptions (especially checked ones) are superior. They do the correct thing — either bubble up if it doesn’t make sense to handle them in place, or have them in as broad of a scope as it makes sense with try-catches. Oh and they store the stacktrace, so when an exception does inevitably happen in your software you will actually have a decent shot of fixing it instead of grepping for that generic error message throughout the program (especially if it’s not even written by you!). I swear people lie to themselves with all those if-errs believing they have properly handled an error condition because it took effort.

Re: Gopher Wrangling: Effective error handling in Go

#194

Post by konart »

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…

>If anything, that makes it harder to understand, how should I knew that Asd is different from asd beforehand?

By reading docs or some kind of "Go by Example"? The same way you learned the difference between `private` and `protected`.

Re: Gopher Wrangling: Effective error handling in Go

#195

Post by oneshtein »

kitd wrote: post #161
lolinder wrote: post #12

Earlier quoted context omitted.

The killer feature of Rust's Result isn't actually the monad itself, it's the ? operator. Being able to concisely say "if there's an error, bail out by returning it" gets you pretty close to exception-level convenience with just a bit more explicit syntax showing where an error might come from.

I've not used Rust. Do you get to add context at the point of bailing?

No, context is not added by default. With third party libraries like anyhow, it's possible to add context[0] before `?` operator in human-readable or machine-readable form:

    a_method().context("Failed to complete the work")?;
    a_method().context(FailedToCompleteTheWork)?;
[0]: https://docs.rs/anyhow/latest/anyhow/trait.Context.html

Re: Gopher Wrangling: Effective error handling in Go

#196

Post by kaba0 »

preseinger wrote: post #37
lolinder wrote: post #12

Earlier quoted context omitted.

The killer feature of Rust's Result isn't actually the monad itself, it's the ? operator. Being able to concisely say "if there's an error, bail out by returning it" gets you pretty close to exception-level convenience with just a bit more explicit syntax showing where an error might come from.

you don't want exception-style "convenience", that's the whole point you want to be able to read code and see a single control flow ? subverts that core requirement

Except that without try-catch blocks you will have n separate control flow instead of a trivial to see pattern.

Re: Gopher Wrangling: Effective error handling in Go

#197

Post by fulafel »

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.

Seeing the "golang" spelling as part of the project name is a sure sign something is not first party.

Re: Gopher Wrangling: Effective error handling in Go

#198

Post by arez »

kaba0 wrote: post #193
nbraxf100 wrote: post #176

Earlier quoted context omitted.

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.

An if err with some random one-liner in the err part is not error handling. You can’t reasonably handle an error condition on a local basis, that’s why exceptions (especially checked ones) are superior. They do the correct thing — either bubble up if it doesn’t make sense to handle them in place, or have them in as broad of a scope as it makes sense with try-catches. Oh and they store the stacktrace, so when an excep…

yes, that's exactly how I also think about Go's error handling. It was always praised the in the early days but it becomes more and more obvious that it's not a good way of handling errors, let alone reading code full of error returns and if err

Re: Gopher Wrangling: Effective error handling in Go

#200

Post by kaba0 »

treyd wrote: post #77
mkehrt wrote: post #32

Earlier quoted context omitted.

In what sense aren't they monads? They have a bind method ("and_then") and a return method (Which is just the variant for constructing the success case, i.e. "Ok" or "Some"). It's more idiomatic to use "map", but that's just a degenerate case of bind. > There's some tricks that have to be done to make them work in a eager evaluation context... Monads have nothing to do with laziness, though. In Haskell, IO actions ar…

After doing some research to refresh my memory I found this old thread: https://users.rust-lang.org/t/what-is-a-monad-and-who-needs-... I believe what I had originally told that makes them not monads is that because Rust goes through some convlutions to fake the laziness of Haskell monads, it makes them not be typed like Haskell monads. For example, the declaration of the `.flat_map` on an iterator is actually `fn fl…

A Monad is just something to which certain properties apply. An easier example to grasp is a Monoid, which is anything that has an associative binary operator, and an identity element. E.g. nonnegative integers’ addition with 0 is such. Or any list with a concat operation, and the empty list.

So even in weaker languages you get monads the difference is that you can’t abstract over them. Your Haskell code can take a Monad, and work with those, most other languages (I believe Rust included) can’t handle them uniformly all over the language. But they can have types that are mathematically speaking monads.

Post reply on HN