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

Discussion: Reduce error handling boilerplate in Golang using '?'

github.com

Post reply on HN
Print view View original

71–80 of 94 posts

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#71

Post by 9rx »

richbell wrote: post #69
9rx wrote: post #67

Earlier quoted context omitted.

> So you can forget to check an error, not notice, and ship a bug. How would you forget, exactly? Your tests are going to blow in your face should you ever leave out an entire feature from the implementation. If you forgot to document that feature in your tests, which is more likely, then you've created a situation of undefined behaviour, not a bug. You've made no claims as to what should happen. All possible behavio…

> How would you forget, exactly? Your tests are going to blow in your face should you ever leave out an entire feature from the implementation. > ... this idea that you are going straight up forget without any notice of your forgetfulness, as fun as a trope as it is, just isn't realistic. By forgetting. Copying `if err != nil` is a mundane and repetitive process, it's easy for your brain to go into auto-pilot. > And…

> By forgetting.

Like in the same way you might forget to write pattern matching code? I mean, that's possible, but the checks and balances are going to let you know. In light of that, what is the significance of forgetting for the few seconds, if that, before getting notified of your forgetfulness? That's not a real problem.

> Pattern matching (with algebraic data types/enum/unions) helps because it forces you to check the error.

Checking the error alone is pointless. You need to also do something with the error, and pattern matching does nothing to help you with that. But that's what tests are for, there to help you with exactly that.

And since your code needs the right branching strategy to get to the point of doing something with the error as validated against the documentation, you also know that your branches are present and working as documented. You cannot possibly forget them after applying the checks and balances. How could you?

All you can really forget to do, maybe, is to document what the program is supposed to do. But in that case the program isn't supposed to do what you forgot to add anyway. Anything missed is undefined behaviour. If you have forgotten to consider what you want your program to do, no language can help you with that!

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#72

Post by thiht »

I really hate that a bare ? makes us lose some info on code coverage. If you only test the happy path, the line is counted as covered. Making the return explicit at least makes it obvious when a line is uncovered.

But my biggest beef is the implicit variable declaration, I can’t stand it. That’s just lazy, bad design.

That’s not a great proposal overall, and I suspect if the same proposal had been made by someone else outside of the Go core team, we would have not heard of it.

I hope it gets rejected.

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#73

Post by richbell »

9rx wrote: post #71
richbell wrote: post #69

Earlier quoted context omitted.

> How would you forget, exactly? Your tests are going to blow in your face should you ever leave out an entire feature from the implementation. > ... this idea that you are going straight up forget without any notice of your forgetfulness, as fun as a trope as it is, just isn't realistic. By forgetting. Copying `if err != nil` is a mundane and repetitive process, it's easy for your brain to go into auto-pilot. > And…

> By forgetting. Like in the same way you might forget to write pattern matching code? I mean, that's possible, but the checks and balances are going to let you know. In light of that, what is the significance of forgetting for the few seconds, if that, before getting notified of your forgetfulness? That's not a real problem. > Pattern matching (with algebraic data types/enum/unions) helps because it forces you to ch…

> Like in the same way you might forget to write pattern matching code?

This is a lengthy response to seemingly ignore, or miss, the point being made.

It is literally impossible to "forget" if you have pattern matching + algebraic data types/enum/unions. Conversely, it is possible and easy with Go.

Nothing you have said acknowledges this.

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#74

Post by jon_richards »

new_user_final wrote: post #66
nonethewiser wrote: post #49

Earlier quoted context omitted.

Yes, same experience. As someone who learned on python then got deep into Typsecript, this was a major bummer when returning to python. Its funny because when I was a beginner in both I strongly preferred python syntax. I thought it was much simpler.

As I have pointed in in my other comment, you can use following syntax in python, ugly but better than multiple and (I don't use python anymore) if dict.get('key', {}).get('key-nested',{}).get....:

Even less pretty for getattr. And then you have a rude awakening about the difference between the missing default behavior of these two functions.

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#75

Post by 9rx »

richbell wrote: post #73
9rx wrote: post #71

Earlier quoted context omitted.

> By forgetting. Like in the same way you might forget to write pattern matching code? I mean, that's possible, but the checks and balances are going to let you know. In light of that, what is the significance of forgetting for the few seconds, if that, before getting notified of your forgetfulness? That's not a real problem. > Pattern matching (with algebraic data types/enum/unions) helps because it forces you to ch…

> Like in the same way you might forget to write pattern matching code? This is a lengthy response to seemingly ignore, or miss, the point being made. It is literally impossible to "forget" if you have pattern matching + algebraic data types/enum/unions. Conversely, it is possible and easy with Go. Nothing you have said acknowledges this.

> It is literally impossible to "forget" if you have pattern matching + algebraic data types/enum/unions.

No, it's entirely possible to forget. That should be obvious. It is a functional necessity for you to be able to forget as you can only type so much at a time. You cannot possibly write code to call a function and perform pattern matching on the result at the exact same moment in time. There fundamentally has to be a period of time where the work will be incomplete, which opens the opportunity to not finish. It should be abundantly apparent to you that that you can forget to finish what you started in such a scenario.

Your checks and balances will alert you of your forgetfulness, but that's true of all languages. The biggest risk is that you will forget to define behaviour. But if you fail to do that, you've got problems even in languages with pattern matching and associated types. ADTs/enums/unions/pattern matching. are not sufficient to define behaviour. Not even close.

Like you said, pattern matching only helps you with checking errors. But there is no reason to check errors in the first place if you don't do something with the error, and for that you need to document what the error condition means for the user. Otherwise you have undefined behaviour. And once you've documented the behaviour, the error checks are confirmed for free anyway. You can't forget. The checks and balances will make it known, spectacularly.

What, exactly, are you trying to accomplish by overselling what is already a fantastic feature by its own merits on the basis of something that isn't at all realistic? If you want to get developers excited about the feature, there are way more compelling attributes to extol!

I have read this exact claim before, for what it is worth. Did you end up here simply because you repeated what you saw elsewhere without actually thinking about it?

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#76

Post by jsnell »

9rx wrote: post #75
richbell wrote: post #73

Earlier quoted context omitted.

> Like in the same way you might forget to write pattern matching code? This is a lengthy response to seemingly ignore, or miss, the point being made. It is literally impossible to "forget" if you have pattern matching + algebraic data types/enum/unions. Conversely, it is possible and easy with Go. Nothing you have said acknowledges this.

> It is literally impossible to "forget" if you have pattern matching + algebraic data types/enum/unions. No, it's entirely possible to forget. That should be obvious. It is a functional necessity for you to be able to forget as you can only type so much at a time. You cannot possibly write code to call a function and perform pattern matching on the result at the exact same moment in time. There fundamentally has to…

The distinction you're not acknowledging is that with pattern matching + algebraic data types you can't do anything with the payload without handling the error case. (You need to write a pattern match to extract the value, and the match needs to be exhaustive.)

With a separate error value, like in Go, that's no longer the case. The code for handling the error and the code for doing something with the payload are totally separate, and don't both need to be present.

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#77

Post by [deleted] »

9rx wrote: post #71
richbell wrote: post #69

Earlier quoted context omitted.

> How would you forget, exactly? Your tests are going to blow in your face should you ever leave out an entire feature from the implementation. > ... this idea that you are going straight up forget without any notice of your forgetfulness, as fun as a trope as it is, just isn't realistic. By forgetting. Copying `if err != nil` is a mundane and repetitive process, it's easy for your brain to go into auto-pilot. > And…

> By forgetting. Like in the same way you might forget to write pattern matching code? I mean, that's possible, but the checks and balances are going to let you know. In light of that, what is the significance of forgetting for the few seconds, if that, before getting notified of your forgetfulness? That's not a real problem. > Pattern matching (with algebraic data types/enum/unions) helps because it forces you to ch…

[deleted]

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#78

Post by madeofpalk »

9rx wrote: post #71
richbell wrote: post #69

Earlier quoted context omitted.

> How would you forget, exactly? Your tests are going to blow in your face should you ever leave out an entire feature from the implementation. > ... this idea that you are going straight up forget without any notice of your forgetfulness, as fun as a trope as it is, just isn't realistic. By forgetting. Copying `if err != nil` is a mundane and repetitive process, it's easy for your brain to go into auto-pilot. > And…

> By forgetting. Like in the same way you might forget to write pattern matching code? I mean, that's possible, but the checks and balances are going to let you know. In light of that, what is the significance of forgetting for the few seconds, if that, before getting notified of your forgetfulness? That's not a real problem. > Pattern matching (with algebraic data types/enum/unions) helps because it forces you to ch…

In Go you can forget to call a function with the correct arguments, and it will not compile, right?

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#79

Post by xigoi »

floating-io wrote: post #19

The biggest issue I have with this proposal is that reading the code in naïve fashion comes up with the wrong answer for me; YMMV. The proposed form-- foo ? { bar } Reads naturally to me as "If foo then bar", when it's actually "If foo's error return exists then bar". I would suggest a different operator character, because this one reads wrongly IMO. Maybe it's just because I originally come from C, where `foo ? bar…

V, which is syntactically similar to Go, uses

  foo or { bar }

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#80

Post by 9rx »

madeofpalk wrote: post #78
9rx wrote: post #71

Earlier quoted context omitted.

> By forgetting. Like in the same way you might forget to write pattern matching code? I mean, that's possible, but the checks and balances are going to let you know. In light of that, what is the significance of forgetting for the few seconds, if that, before getting notified of your forgetfulness? That's not a real problem. > Pattern matching (with algebraic data types/enum/unions) helps because it forces you to ch…

In Go you can forget to call a function with the correct arguments, and it will not compile, right?

No, definitely not. The compiler couldn't care less if your arguments are correct. Consider:

   func cleanupTemporaryDir() {
       os.RemoveAll("/")
   }
You might have some very unhappy users if you ship that. Of course, as you would have documented your intended behaviour, the mistake is going to get caught when you run your tests, making it abundantly clear that you screwed up before bad things happen. Like before, you're not going to end up out.

Sure, a language with a deeper type system can place restrictions on what kinds of values you can pass in. "/" would be prevented by the type checker, letting it be known as you type and not later when you run the tests. That is nice. Nobody is going to deny that. But this act as if it is the only thing that will save you is completely disconnected from reality. Our world does not exist in this imagined vacuum where when one thing doesn't exist nothing does.

Post reply on HN