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

Declined Proposal: A built-in Go error check function, “try”

github.com

Post reply on HN
Print view View original

191–200 of 425 posts

Re: Declined Proposal: A built-in Go error check function, “try”

#191

Post by tyre »

dnautics wrote: post #183
poweroftrue wrote: post #168

Just try writing three Go programs with error handling, then, try other languages! I was pissed at first. However, now I cannot code in any language without overusing try and being scared of each line. Using Go's error handling is actually making your code smarter, I mean, you don't want your code to break with a weird message because of something stupid. The simplest example is adding a default-path whenever I'm rea…

try errors in elixir: with {:ok, val1} handle_notfound_error() {:error, :eperm} -> report_permission_error() _ -> raise("don't worry this process is supervised, let it crash!") end low cyclomatic complexity makes for a nice user experience, and you learn the philosophy of "if it doesn't work, just turn it off and on again". Why be scared? Just let it go. The VM has your back.

yes! Or using function heads, though for cases with many errors this can end up being less clear.

Rust's `match` also does an ok job

Re: Declined Proposal: A built-in Go error check function, “try”

#192

Post by hacknat »

thatswrong0 wrote: post #110
nkozyra wrote: post #81

Earlier quoted context omitted.

> My guess is that gofmt is a huge factor in this It really is. My code looks like your code and the next person's code. Go is opinionated and strict and that makes reading other people's code so much easier

I wish gofmt would let you set a desired line length and break it for you.. prettier has me spoiled in that regard

You can always set your defaults for your editor.

Re: Declined Proposal: A built-in Go error check function, “try”

#193

Post by kerng »

Thaxll wrote: post #154
KirinDave wrote: post #120

Earlier quoted context omitted.

I guess then I have to ask, why would try() make that worse? Because I can't stand Golang error handling. It's repetitive, it's error prone, and other language features interact with it so that when you make a mistake it can be as hard as a double free to track down where the erroneous default value was introduced. On the other hand, using Rust, Ocaml, F# or Haskell I understand how my code composed and I can be conf…

How returning (val, err) is error prone? It's verbose but it's clear and definitely not error prone. I spent so much time working with Java and useless giant stacktraces or with Python and people not knowing what to do inside a try / except.

Copy/paste is very error prone. Golang code is full of it. I see lots of similarities between Visual Basic and Golang, incl. the passionate communities behind the languages.

Re: Declined Proposal: A built-in Go error check function, “try”

#194

Post by millstone »

crimsonalucard wrote: post #86
guessmyname wrote: post #36

Earlier quoted context omitted.

I am one of the Go programmers who didn’t like this proposal. I also spent a significant amount of time discussing with many people, including the Go team, and I am glad the proposal was declined, not because I like “if err != nil {…}” but because the proposal to add “try()” was not solving a good problem. Many, and I would say, every Go programmer wants better error handling, but “try()” was not it. I hope the Go te…

The maybe monad is the best solution for this. Usually to support this the language needs Enum support and a proper type system neither of which golang has. So I'm ok with the developers just baking in syntax for an error monad with specific sugar for extracting the value or handling an error.

Why is a monad the “best” solution? Best according to what criteria?

Special purpose syntax can buy you a lot more. For example Swift’s try makes it obvious which statements contain error handling without burdening each expression.

Re: Declined Proposal: A built-in Go error check function, “try”

#195

Post by tdb7893 »

pbreit wrote: post #172
wybiral wrote: post #33

This hits at something fundamental about Go, which is what I like the most about it... It's a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you're forced to carry them up the chain. Do I particularly like managing errors that way? No, but I do think that it improves the transparency and qual…

If it matters to anyone, this novice finds “if” easier to understand than “try”. Very refreshing for novice to agree on expert on a topic.

I don't think many people think that "if" is hard to understand. My problem with the "if" statements is that a third to half of the lines in a couple of my codebase are roughly the same copy pasted error handling (the codebases use the os package, which has pretty much every function return errors) and having all of that same boilerplate just clutters the code and makes it harder to read. It would be a real readability win to have less boilerplate in Go.

Re: Declined Proposal: A built-in Go error check function, “try”

#197

Post by kartickv »

djur wrote: post #167
Thaxll wrote: post #154

Earlier quoted context omitted.

How returning (val, err) is error prone? It's verbose but it's clear and definitely not error prone. I spent so much time working with Java and useless giant stacktraces or with Python and people not knowing what to do inside a try / except.

Repetition and verbosity in a language can create errors in at least two ways. First, by the developer losing track of which error case is which (and/or copy-pasting error-handling logic) and doing the wrong thing in the error case. Second, by reviewers who have become trained to notice and gloss over error-handling boilerplate not noticing when there's something wrong with a particular case. Concise languages can be…

Interesting perspective. Are you expressing an opinion about "explicit is better than implicit", or is your point on a different axis?

I suppose concise / implicit is fine when the thing that's being hidden can't go wrong, like in:

[i * 2 for i in 1...10]

The loop counter increment logic can't possibly go wrong, so it's fine to not think about it.

Regarding error-handling, don't you want to think about? If you're calling a() followed by b(), what should you do if a() fails? In some cases, b() shouldn't be called, but in others, it should, like deleting a temp file. And if you have to think about it, it's better to be explicit?

Re: Declined Proposal: A built-in Go error check function, “try”

#198

Post by wvenable »

ben509 wrote: post #184
tempsolution wrote: post #55

Earlier quoted context omitted.

You can't compare it to Java checked exceptions. Java checked exceptions are one of those billion dollar "mistakes". It is the single worst thing in Java for me. Checked exceptions add nothing and break almost everything around clean design & code. For that comparison to work, java would have needed to only have checked exceptions, with some added language features to deal with them cleanly, and then it might actuall…

I thought extending _throws_ with an _as_ clause would make it far more manageable: void foobar() rethrows IOException as AppException rethrows FooError, BarError as WtfError { Being able to express that a bunch of internal exceptions should be wrapped in an application exception would save a ton of boilerplate. The exception syntax itself is also clunky. If you have a complex expression, you have to extract it and a…

> Being able to express that a bunch of internal exceptions should be wrapped in an application exception would save a ton of boilerplate.

It would but I think it's the wrong approach -- you're actively changing the error information that really provides no additional value except to make the type-checker happy because the alternative is too verbose.

Re: Declined Proposal: A built-in Go error check function, “try”

#199

Post by wvenable »

gridlockd wrote: post #115
tempsolution wrote: post #55

Earlier quoted context omitted.

You can't compare it to Java checked exceptions. Java checked exceptions are one of those billion dollar "mistakes". It is the single worst thing in Java for me. Checked exceptions add nothing and break almost everything around clean design & code. For that comparison to work, java would have needed to only have checked exceptions, with some added language features to deal with them cleanly, and then it might actuall…

> Littering your code with try-catch is what makes exceptions infeasible for error handling. I honestly don't see the big difference between littering your code with if/else blocks versus littering them with try/catch blocks. Can you elaborate?

Both are bad.

Re: Declined Proposal: A built-in Go error check function, “try”

#200

Post by jeremyjh »

tyre wrote: post #191
dnautics wrote: post #183

Earlier quoted context omitted.

try errors in elixir: with {:ok, val1} handle_notfound_error() {:error, :eperm} -> report_permission_error() _ -> raise("don't worry this process is supervised, let it crash!") end low cyclomatic complexity makes for a nice user experience, and you learn the philosophy of "if it doesn't work, just turn it off and on again". Why be scared? Just let it go. The VM has your back.

yes! Or using function heads, though for cases with many errors this can end up being less clear. Rust's `match` also does an ok job

Match isn't really comparable to Elixir's with. The Elvis operator is closer, you can have a chain of commands with early exit.
Post reply on HN