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

281–290 of 425 posts

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

#281

Post by danielparks »

natefinch wrote: post #98
KirinDave wrote: post #45

Earlier quoted context omitted.

> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics. That lead to a world where folks felt "forced" to use Java, and that's a sti…

Literally the first non-trivial code I wrote in go (running a bunch of goroutines to download a ton of files from a website in parallel)... I knew exactly where and how things could fail and where things were failing just by looking at the code. Coming from C++ and C# and Python, there was no comparison. I had never been so confident in the code I'd written, even though I was a newbie at Go and a veteran of the other…

> Literally the first non-trivial code I wrote in go… I knew exactly where and how things could fail and where things were failing just by looking at the code.

Could you give an example?

I think you’re talking about something different than what I’m understanding. One of the major frustrations I have with Go error handling is the lack of stack traces, which means I often have to modify code in order to find out where an error occurred.

I’m pretty sure that’s not what you’re talking about, though.

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

#282

Post by danielparks »

jchw wrote: post #61
KirinDave wrote: post #45

Earlier quoted context omitted.

> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics. That lead to a world where folks felt "forced" to use Java, and that's a sti…

>So long as we can all agree that it feels super bad, I guess this is fine. Actually, I don't think everyone agrees it feels super bad. I personally like having all of my error handling be explicit, painfully explicit even. >approaches the Java world back with checked exceptions where principle trumped ergonomics. I also have to disagree here. To me, checked exceptions are the worst of both worlds. Here you have addi…

> Go doesn't even really force you to check your errors, it just makes it harder to accidentally not check them.

Quite the opposite. You have to explicitly ignore exceptions, whereas it’s easy to accidentally miss an error in Go. For example, how many times have you seen this?

    defer f.Close()
Close() returns an error; this code ignores it.

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

#283

Post by mcbits »

thatswrong0 wrote: post #244
mcbits wrote: post #126

Earlier quoted context omitted.

If a tool is going to enforce line length limits, I'd rather have it spit a warning/error than silently try to guess a good place to break the line automatically. Otherwise, an editor tool that soft-wraps long lines at the (often poorly) guessed location without touching the code would be better.

But that’s the thing about prettier - it wraps exceptionally well because it actually parses the AST. I never think about how I space my JavaScript anymore because it always does it correctly.. it’s one less thing to get in my way when I code

The number of options that prettier exposes (despite boasting about being "opinionated", i.e. disregarding the user's opinions) suggests that there are people with different aesthetics or accessibility needs who would not consider one style to be always correct.

IMHO we're about 10 years overdue for committing a canonical representation of that AST to version control instead of treating a particular serialized visualization of it as the single source of truth (and spending countless hours debating which format is "good enough" for everyone in every situation).

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

#284

Post by jbverschoor »

jpittis wrote: post #188
Thaxll wrote: post #179

Earlier quoted context omitted.

I'm not a Rust expert but afaik Rust doesn't enforce error checking since you explicitly need to unwrap(). It's very possible to panic because you forgot to check something. It's similar in Go since you can't compile with unused variable so you need to explicitly discard the error with _. Ex: result, _ := func() This is for multi-value returns, for single value you can even omit the _ https://golang.org/doc/effective…

Having unwrap() in your Rust code is like littering your code base with panic(). It’s not appropriate to use in most production code, but is convenient in prototypes, examples and tests. Your example re Go errors is incorrect. The go compiler allows you to ignore errors in returns without any compiler error. For example err := doThingThatErrs() and doThingThatErrs() are both valid Go code.

Then how is this better than anything else? Except for syntactical sugar for:

Try Return [Bla(), null] Catch err Return [null, err] End

I do like this syntax better, bc the different scopes cause a lot of nesting

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

#285

Post by Someone »

tdb7893 wrote: post #195
pbreit wrote: post #172

Earlier quoted context omitted.

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 readabili…

Had anybody ever thought about using ‘go generate’ to insert missing ‘if err… return’ clauses with descriptive error messages?

If so, where’s (s)he buried? :-)

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

#286

Post by tsimionescu »

weberc2 wrote: post #164
KirinDave wrote: post #45

Earlier quoted context omitted.

> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics. That lead to a world where folks felt "forced" to use Java, and that's a sti…

I understand what you mean by “bad ergonomics”, but I think of those things as “ergonomics in the small”. You end up writing for loops and error checks. It’s verbose but not complex, and it’s all very localized. Further, people get really hung up on these small language issues and miss go’s killer features: simplicity and consistency. Go is a small, simple language with few surprises. No guesswork about which feature…

Go the language is surprisingly complex and error prone compared to other GC languages because of its decision to allow explicit references. This adds an extra layer of semantics to nearly every aspect of the language.

For example, the semantics of the for-over-collection statement in Java are that it repeats the block of code, with the loop variable holding each value of the collection in turn. In Go, the equivalent statement also needs to document what it means to take the reference to the loop variable. Composite data types have semantics for taking references to sub-parts (struct and arrays/slices allow taking references, maps do not).

Slices and arrays are another complicated area of the language, with gotchas like append sometimes modifying the original array, sometimes not.

Regarding splits, you still have that in Go as well - do you use goroutines as coroutines, sending copies of objects through channels? Or do you use them as threads, with shared memory and locking? Do you use the testing package as is, with its lack of any user-friendly asserts? Or do you pick up an assertion library? Do you use raw http,or something la Gorilla? Sql or some ORM? Do you log to stdout, or do you pick up a logging library?

Regarding gofmt, I personally can't understand the passion some people have for enforcing a common style.

Regarding build tools, Go is hardly unique among modern languages in having built-in tooling for that. It's relative ease of deployment also means that Go's build tools can't be used alone in a multi-language project, so many of the apparent simplicity is only useful in a subset of projects that actually use only Go. Even then, if you have any other build artifacts you may find you need to reach for something other than Go's tooling. By comparison, Maven can easily handle a Java+minor bits-in-other-languages project out-of-the-box.

Not to mention that Go is probably the only language in any kind of popular use today that doesn't have a built-in way to interface with C code (you need to use a separate compiler if you want that!).

To me, Go has a single killer feature: binary and memory size for a GC language. And Java may be catching up on that area...

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

#288

Post by didibus »

qtplatypus wrote: post #265
didibus wrote: post #235

Earlier quoted context omitted.

I don't know go, so I'm confused here. If nothing failed, the error is just made silent? The program will move to doOtherThing, as if nothing failed, and everything will move forward?

The error was just ignored. if doThing() had some side effect that doOtherThing() depended on then you will never know why doOtherThing() isn't working the way you expect it to be.

Ya that seems pretty unsafe to me. I'm not sure then why others suggest the Go error handling makes things safer. Silent failures have always been some of the most impacting issues in the systems I've maintained. They cause slow corruption and they take a long time to be found, at that point, the damage is done and hard to revert.

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

#289

Post by VMG »

sagichmal wrote: post #275
tsimionescu wrote: post #274

Earlier quoted context omitted.

The difference with catch blocks in Java, C++ or Python is that you only need to write them when you actually have something g meaningful to do. If you only need to propagate the error or cleanup resources then propagate the error, then all you would write is... Nothing. And cleanup+propagation is by far the most common error handling strategy. In Java and Python exceptions even add context for you automatically to h…

One foundational principle of Go is that the sad path is at least as important, and maybe more important, than the happy path. The best Go programmers I know write the sad path of their programs first, and then backfill the happy-path logic. So: > you only need to write [error checking] when you actually have something meaningful to do. Although it's the subject of a lot of ridicule, `if err != nil { return err }` is…

> Errors in Go are, at a minimum, annotated with contextual information before being returned.

What surprised me when I last wrote Go was that there was no out-of-the-box solution to adding a stack trace to the error.

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

#290

Post by eikenberry »

apta wrote: post #213
eikenberry wrote: post #170

Earlier quoted context omitted.

> I think the Golang community is going to find itself growing more slowly as folks increasingly realize other options offer similar benefits without the bad ergonomics. I'm curious about what you think these other options are? There are of course tons of languages and you can find just about any set of features you want, but the combination Go has along with the momentum, community, etc. it has means that there are…

> it has means that there are not many that can compare in its niche Which is? "devops"? Otherwise, offerings on the JVM and .NET are strictly superior. And now with native compilation being available for both platforms, they will also be a better fit at devops than golang. Other alternatives include Rust.

I would say the niche is basically clouds systems programming and general server side apps.

JVM based language can't compare due to the JVM. The last thing you want for that type of programming is a huge, complex virtual machine to worry about. That plus memory issues, slow compiles, complex deployments makes it not really in the running.

The .net based languages are a bit more interesting, but they have a _lot_ of ground to make up for due to their roots. Not having their roots in the native OS/culture of the internet will make it tough road.

Rust is nice but has its flaws as well. I think it will end up nailing a lot of use cases where C++ would have been picked before. Go really targets what JVM based languages or things like Python+C would have been used for... not C++. That is, I think it is really a different niche.

Post reply on HN