Declined Proposal: A built-in Go error check function, “try” • Hacker News Board

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

#411

Post by mikeschinkel » Fri, Jul 19, 2019, 6:19 PM UTC

pjmlp wrote: post #408

mikeschinkel wrote: post #395

Earlier quoted context omitted.

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.

Given that I have worked with VB long before .NET even existed, I have a broader view of it than just the more recent criticisms.

VB's biggest problem IMO is that it tried to compete with C# instead of maintaining its original raison d'être which was to be a highly productive tool that required very little programming skill to be able to start building real solutions for business use.

But I digress...

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

#412

Post by mikeschinkel » Fri, Jul 19, 2019, 6:46 PM UTC

tsimionescu wrote: post #269

wybiral wrote: post #117

Earlier quoted context omitted.

> any code search reveals that "if err != nil { return err }" is everywhere Code searches in languages with exceptions tend to wrap the tryblocks around massive portions of code instead of the individual function calls to the point that you have a top level doing: try: ...program here... except: print('¯\_(ツ)_/¯')

But that is exactly how error handling usually works, especially if cleanup is handled separately - you just need to propagate the errors, usually all the way up to the user, who is the only one who can take a meaningful decision. Almost all actual error handling in code is either error translation and re-throw, resource cleanup, or automatic retries (sometimes you retry the same request, sometimes you try a fallback…

> That's why exceptions work so well in most languages

But there are many people including some well-known and highly-respect people who believe that exception handling in fact does not actually work well:

- https://www.joelonsoftware.com/2003/10/13/13/ - https://blogs.msdn.microsoft.com/larryosterman/2004/09/10/st... - https://www.atlassian.com/blog/archives/exceptions_are_bad - https://stackoverflow.com/a/1736320/102699 - http://xahlee.info/comp/why_i_hate_exceptions.html - http://www.lighterra.com/papers/exceptionsharmful/

#justsaying

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

#413

Post by mikeschinkel » Fri, Jul 19, 2019, 6:54 PM UTC

tsimionescu wrote: post #320

Crinus wrote: post #314

Earlier quoted context omitted.

FWIW when debugging i prefer the second style if for no other reason than that i can place a breakpoint in doOtherStuff while skipping doStuff. Also reading it, it is more obvious that the code calls both doStuff and doOtherStuff (though with just two calls it isn't a big different, imagine having a 2-3 more calls in there). (also why debuggers still insist on line-based breakpoints is beyond me, why can't i right cl…

You could also write the first function body as Stuff thing1 = doStuff() return doOtherStuff(thung1) It's still easier to read without the explicit error handling.

After working with Go for a while I actually find code with error handling easier to read because it is more clear to me what it happening. I look for the error handling as an indicator that the code can actually fail vs. code that cannot fail.

And maybe it's because I've developed a very consistent pattern, and when I find that there are too many errors to handle in a function it helps me realize the function is probably doing too much and needs to be split into multiple functions.

IMO it is all about training your brain and being accepting enough to work in the dialect of the land, as opposed to demanding to speak English when living in France. :-)

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

#414

Post by AsyncAwait » Fri, Jul 19, 2019, 7:02 PM UTC

pjmlp wrote: post #378

AsyncAwait wrote: post #240

Earlier quoted context omitted.

To be fair, any decent editor will expand 'er' to that, no need to type it manually.

So a typical criticism of Java and IDE dependency becomes a non-issue when talking about Go's shortcomings.

Eh, if you consider optional macro expansion an 'IDE' feature, (even gedit can do it), I guess.

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

#415

Post by mikeschinkel » Fri, Jul 19, 2019, 7:04 PM UTC

pcwalton wrote: post #166

sagichmal wrote: post #144

Earlier quoted context omitted.

> There isn't a meaningful difference in cumbersomeness between having two try-catch blocks and two if-err blocks As demonstrated by the sibling comment to mine, this is wrong. > In practice programs written in languages with [exceptions] tend to have better error diagnostics than Go programs. Anyone who's spent time on teams working in exception-oriented languages like C++ or Python knows this to be clearly false. >…

I'm not saying you should use Rust! I'm saying that Go should add try.

I was one of the many who argued strenuously that they not add try(). I spent an entire day writing up my reasons who I posted to the ticket on GitHub.

Bottom line, try() had too many flaws — especially related to consistency with the rest of Go — to be an appropriate addition to the Go language.

Adding try() to Go would be like adding a disco ball to the Sistine Chapel. Sure, disco balls have their place, but some places are just not appropriate for disco balls.

Or as Yoda says:

"Do or do not. There is no try." (Fortunately!)

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

#416

Post by mikeschinkel » Fri, Jul 19, 2019, 7:08 PM UTC

diminoten wrote: post #186

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…

Yeah but as a prospective Go user, the fact that the language is opting for pain turns me off. Enjoy your ecosystem, I'm going to continue to use languages that actually like me, and care how my experience is.

I would say you can't know if it will cause you pain until you try it. Using the metaphor, some people actually like certain types of pain, and pain is something that is very hard to understand simply by listening to the complaints of others.

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

#417

Post by mikeschinkel » Fri, Jul 19, 2019, 7:10 PM UTC

ghostpepper wrote: post #158

KirinDave wrote: post #102

Earlier quoted context omitted.

> It is the single worst thing in Java for me. Checked exceptions add nothing and break almost everything around clean design & code. Should I compare it to "Golang Dependency Hell Claimed My Project?" > 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 actually have been a viable design. Why? That's not…

> Should I compare it to "Golang Dependency Hell Claimed My Project?" As someone just learning Go, what is Golang Dependency Hell?

As someone who started Go when Modules were already available, I don't think you'll run into it (unless you try to use older packages.)

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

#418

Post by mikeschinkel » Fri, Jul 19, 2019, 7:12 PM UTC

meddlepal wrote: post #254

geodel wrote: post #159

Earlier quoted context omitted.

> Should I compare it to "Golang Dependency Hell Claimed My Project?" Of course you can. But it would be hilarious considering Java Module system (Jigsaw) which took decade in making still does not support versioning. People are left to use bloated crap like Maven or Gradle. But since these products are called "enterprise grade" developers are not supposed to call them crap that they really are.

Ah yes the good 'ol "bloated crap" argument developers love to fall back on when they don't know what they're talking about. What exactly is "bloated crap" about maven? It works exactly as advertised and a heck of a lot better than go modules/vgo. If you say XML you lose (it is a config fmt get over yourself...). If you say it downloads the world I suggest you look at the output scroll by on any decent sized project…

> If you say XML you lose (it is a config fmt get over yourself...).

"Besides that Mrs. Lincoln, how was the play?"

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

#419

Post by mikeschinkel » Fri, Jul 19, 2019, 7:18 PM UTC

philwelch wrote: post #334

stcredzero wrote: post #92

Earlier quoted context omitted.

So long as we can all agree that it feels super bad, I guess this is fine Exceptions feel super good, even as you're taking too many shortcuts and glossing over things. Proper handling of the unhappy paths is often going to feel like a slog, because it often is complicated, and it's often a slog. Glossing over error handling in golang can feel bad exactly when it should.

In some contexts, exceptions are just cleaner and easier. If I’m writing a web backend, my error handling is going to almost always be, “stop trying to do things and generate a 4xx/5xx response”. Throwing an exception from anywhere and then handling it at the top of the request handling does that without having to tediously carry errors all the way up the call stack.

But then you have to spend lots of extra time trying to discern between the errors that were okay, and the errors that actually indicate flaws in your code.

As they say, an ounce of prevention...

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

#420

Post by mikeschinkel » Fri, Jul 19, 2019, 7:20 PM UTC

philwelch wrote: post #369

stcredzero wrote: post #358

Earlier quoted context omitted.

In some contexts, exceptions are just cleaner and easier. Definitely. The question is, are the benefits in those contexts worth the cost of the potential abuses? As a codebase and company get larger and larger, the higher the probability that a problem will get into the codebase. There is an analogy here with C++ templates and with method_missing meta-programming. There are some contexts where they make things a lot…

While true, HTTP services in particular are a very, very common context.

Then use panic() and recover() for that special type of use-case. Just as easy as exception handling.