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

401–410 of 425 posts

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

#401

Post by ngrilly »

dalyons wrote: post #310
alexbanks wrote: post #209

This thread is rife with "Go should have Try because I want Try" that also seem to be made by developers that do not write Go. It seems confusing to me that voices generally involved from Go are so demanding of its maintainers. Curious, are there full-time (or at least Primary) Go developers that are upset by the lack of Try?

I write a lot of go in the context of web(micro)services. In stateless services it’s almost always better to bubble up the error and let the caller retry. So I hate the current error handling in this context, it’s a verbosity tax with no value add. Am ambliviant about try though

Have you contributed to the discussion about `try` in the GitHub issue tracker?

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

#402

Post by ngrilly »

segmondy wrote: post #349

Lack of try and go's error handling is part of my attraction to go. Explicit handling of error is much better than implicit and having to guess how things might get handled.

try may have drawbacks but not this one. try is perfectly explicit. There is no implicit error propagation.

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

#403

Post by ngrilly »

qtplatypus wrote: post #260
bmurphy1976 wrote: post #169

Earlier quoted context omitted.

I think try is jumping the gun. Implementing try now is splitting the community and introducing what will likely be new technical debt. It doesn't fundamentally change things, it only makes the language more complicated in a way that's both weird* and likely to become obsolete once generics are a thing. They should focus on xerrors for now and wait until generics are implemented and try again. * weird as in there are…

I expect that once we get generics we are going to get a host of differently implemented variations of the error monad none of which is used by the standard library. Which I think is worse then try. In a broader sense I am deeply irritated by the part of the go community's culture that seemingly sees any effort to make go more "don't repeat yourself" to be making it more complex. With no acknowledgment that avoiding…

I share your irritation and I'm a bit worried about the language future because of this conservatism.

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

#404

Post by etaioinshrdlu »

qtplatypus wrote: post #273
etaioinshrdlu wrote: post #270

Earlier quoted context omitted.

Indeed, I like to think of Go as basically the opposite of Lisp.

Its funny that Go keeps going on how simple it is. Which scheme is much more simple then go will ever be.

Perhaps Scheme is simple, but Go tries to force the user to keep their program simple...

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

#405

Post by dnautics »

didibus wrote: post #347
dnautics wrote: post #263

Earlier quoted context omitted.

If you're rethrowing the exception, what happens in the VM if that exception is not caught? IIRC, the VM exits, so, it's not at all identical. There are potentially severe nonlocal effects and you're already coding defensively by putting a catch/rethrow.

As far as I know, you didn't get a supervisor for free in Elixir either, you decided to use one, and spent some time determining how to configure it to recover from its child processes failing. In Java, you can similarly put a try/catch at a higher level in the call tree and decide to retry everything on error. Now, Erlang processes don't share state, so that makes them easier to "handle" when they crash, I'm not den…

and then you have to trap InterruptedException... etc. It's not straightforward.

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

#407

Post by mvndaai »

pixelrevision wrote: post #72
curtis wrote: post #11

A lot of Go programmers didn't like this proposal at all. I'd like to think this is just because they didn't think it was good enough. However, it seems that many, many Go programmers didn't like it because they think Go error handling is just fine the way it is.

I don't really care about try/catch, I'd just rather they come up with a standard for wrapping errors so there is more visibility as they get bubbled up. Currently you can write code to do this but most packages will not be doing the same. There also will always be some member of your team fighting you about "simplicity" when you talk about wanting to have more info than a string to log.

The go 1.13 version of errors will have the `Is`, `As`, and `Unwrap` which make this almost a standard in go. They expect you to be able to unwrap but have not created a normal way to wrap. https://tip.golang.org/pkg/errors

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

#408

Post by pjmlp »

mikeschinkel wrote: post #395
pjmlp wrote: post #373

Earlier quoted context omitted.

With the difference that Visual Basic is an academic language full of needless features from Go's community point of view.

Visual Basic is hardly academic; they is a tremendous amount of line-of-business code that has been written in VB over the past 25 years. But yeah, Go dev do not see VB's features as being "features."

The point was that many of VB.NET features are what many in the community attack as being academic and not worthy of being adopted by Go.

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

#410

Post by OvermindDL1 »

prirun wrote: post #381
djur wrote: post #257

Earlier quoted context omitted.

My preferences are that error handling is expressed in and enforced by the type system (Haskell's Maybe/Either, Rust's Result), that common error handling tasks be supported by the standard library and by specialized syntax when necessary (Haskell's many Monad/Applicative tools, Rust's "?" operator), and that if a developer neglects or chooses not to handle an error that the most likely outcome is that it bubbles up…

the amount of work they do -- and the code produced, and thus the work reviewers have to do -- should be proportionate to how unusual the necessary error handling is. Great comment. I would add how unusual _and critical_ . One of the things I love about Python is that while I know errors can occur on practically every statement written, I only have to add error handling for likely / expected / critical errors. Any un…

Honestly when I look to rewriting a python thing to be 'faster' either try using PyPy first, or rewrite it in OCaml instead. OCaml is extremely simple, similar to python in a lot of ways (GIL and all), but runs at native code speeds, near C the majority of the work, and super easy to bind to C libraries if you need.

Or try Rust. ^.^

Post reply on HN