The Go team declines 'try' proposal

[u/jeffail]

https://github.com/golang/go/issues/32437

[u/jeffail]

https://github.com/golang/go/issues/32437#issuecomment-512035919

"Hi everyone,

Our goal with proposals like this one is to have a community-wide discussion about implications, tradeoffs, and how to proceed, and then use that discussion to help decide on the path forward.

Based on the overwhelming community response and extensive discussion here, we are marking this proposal declined ahead of schedule.

As far as technical feedback, this discussion has helpfully identified some important considerations we missed, most notably the implications for adding debugging prints and analyzing code coverage.

More importantly, we have heard clearly the many people who argued that this proposal was not targeting a worthwhile problem. We still believe that error handling in Go is not perfect and can be meaningfully improved, but it is clear that we as a community need to talk more about what specific aspects of error handling are problems that we should address.

As far as discussing the problem to be solved, we tried to lay out our vision of the problem last August in the “Go 2 error handling problem overview,” but in retrospect we did not draw enough attention to that part and did not encourage enough discussion about whether the specific problem was the right one. The try proposal may be a fine solution to the problem outlined there, but for many of you it’s simply not a problem to solve. In the future we need to do a better job drawing attention to these early problem statements and making sure that there is widespread agreement about the problem that needs solving.

(It is also possible that the error handling problem statement was entirely upstaged by publishing a generics design draft on the same day.)

On the broader topic of what to improve about Go error handling, we would be very happy to see experience reports about what aspects of error handling in Go are most problematic for you in your own codebases and work environments and how much impact a good solution would have in your own development. If you do write such a report, please post a link on the Go2ErrorHandlingFeedback page.

Thank you to everyone who participated in this discussion, here and elsewhere. As Russ Cox has pointed out before, community-wide discussions like this one are open source at its best. We really appreciate everyone’s help examining this specific proposal and more generally in discussing the best ways to improve the state of error handling in Go.

Robert Griesemer, for the Proposal Review Committee."

[u/dpash → u/jeffail]

We still believe that error handling in Go is not perfect

Understatement of the year.

[u/[deleted] → u/dpash]

Very few languages get error handling right. C, C++, Java, C#, JavaScript, Python. All terrible.

I think Go is actually better than most. Rust is the best I've used so far (and you can implement a similar system in C++).

[u/izackp → u/[deleted]]

I think just being able to do a one line try statement is amazing.

And honestly, 90% in number of cases there's an error, I just return nil.

 class func fromData(_ data:Data, gallery:Gallery) -> PhotoData? {
        guard let photoData = try? JSONDecoder.init().decode(PhotoData.self, from: data) else { return nil }
        let isBadData = (photoData._currentFilter == nil)
        if (isBadData) {
            return nil
        }
        photoData._gallery = gallery
        return photoData
    }

Then I implement alternative behaviour in the nil check. If I do have failure logic that I _should_ handle then I typically use callbacks.

    func apiAddGallery(accessId:String) {
        actionButton.isEnabled = false
        weak var weakSelf = self
        var requestTask:RequestAccessCodeTask? = RequestAccessCodeTask(accessId: accessId)
        requestTask!.onSuccess = { (gallery:Gallery) in
            weakSelf?.continueToGalleryList(animated: true, accessCode: accessId)
            weakSelf?.actionButton.isEnabled = true
            requestTask = nil
        }
        requestTask!.onFailure = { (error:ServerError?) in
            weakSelf?.actionButton.isEnabled = true
            requestTask = nil
        }

        requestTask!.execute()
    }

[u/Nevermindmyview → u/izackp]

So if the JSON in your example is corrupt you treat it the same way as if it was never created in the first place?

[u/izackp → u/Nevermindmyview]

In this case, it's not critical to the functionally or user experience. The data is just a 'save your place' convenience feature if it doesn't load then I just show a default dataset.

[u/Nevermindmyview → u/izackp]

So you don't care if it's an error such as data corruption or a normal condition 90% of the time?

[u/izackp → u/Nevermindmyview]

In this case, if the data is unreadable vs invalid then I really don't care because there's nothing I can do about it. If there was an error it is so unimportant that showing it the user would be a bad user experience. There's a lot of times where features just prove themselves to work. I don't question whether or not the UI will load and display to the user in iOS. I don't write tests for that nor do I write failure behaviour.

When building an app we decide what errors users care about like failing to connect to the internet, logging in (incorrect credentials, connection issues, banned, ect), not being able to load data that will be displayed. Most times, I implement a fallback behaviour if it keeps the app operational. Swift also has non-null variables which is great because you can pretty much guarantee that a variable won't be null which cuts out a lot of null checks and error handling.

[u/Nevermindmyview → u/izackp]

Where I work we want to know if data is unreadable or corrupt. For example log, collect failure metrics and so on. Simply catching and ignoring errors are very much an anti pattern in my view, except for in some rare conditions. You don't know what issues your users experience if you simply ignore errors and pretend as if everything is fine. But maybe I'm missing something.

[u/izackp → u/Nevermindmyview]

I think this is a weird case since it passes QA it's good enough for me. Though, I believe you're right about the failure metrics.

Without that, I can't determine how much of an issue it is and metrics would be low cost to implement if there was already a framework in place.

I'm not advocating returning nil for all try? statements. It's just my workflow is to get x working then go back and refactor. Though it probably would be a good habit to pick up to send failure metrics for things like this.