SoylentNews is people
SoylentNews
from the No!-Try-not.-Do,-or-do-not.-There-is-no-try.-YODA dept.
The Go language will not be adding a "try" keyword in the next major version, despite this being a major part of what was proposed for version 1.14.
Go, an open source language developed by Google, features static typing and native code compilation. It is around the 15th most popular language according to the Redmonk rankings.
Error handling in Go is currently based on using if statements to compare a returned error value to nil. If it is nil, no error occurred. This requires developers to write a lot of if statements.
"In general Go programs have too much code-checking errors and not enough code handling them," wrote Google principal engineer Russ Cox in an overview of the error-handling problem in Go.
A try statement was proposed to help reduce the coding burden. Upon further reflection:
That proposal has now been abandoned. Robert Griesemer, one of the original designers of Go, announced the decision in a post yesterday.
[...] “Making an exit point of a function that isn't a return, and is meant to be commonplace, may lead to much less readable code,” said one user.
The outcome is a good one insofar as the Go community has proved able to make and withdraw a major proposal without rancour. And as for error handling, no doubt the team will, um, try again.
(Score: 2, Interesting) by Anonymous Coward on Thursday July 18 2019, @06:52AM (1 child)
Exception abuse annoys me to no end. For instance in web development you can use ETags. An ETag is basically a hash of a page determined by the server that represents the content of a page. So a client can specify an etag, and if they match then the server sends back nothing but a message indicating that the etags match. The reason for this is that its then assumed that the client has the page's content locally cached. Off topic this is also a way some unscrupulous websites engage in tracking. They send unique etags to each user and when that etag gets sent back later on, it basically works as an identifier for the client.
Anyhow, the point of this all is that in C# there is a WebRequest system. How does the WebRequest system handle an etag match on a read request? It throws a WebException instead of returning some reasonable value, or even null. A proper and expected class of return from the server should not trigger an exception. It's horrible nasty naughty language abuse. If I could find the intern that wrote this nonsense I'd spit my half downed breath mint at them. Actually I wouldn't, but I'd glare menacingly at them. Thanks for now filling my output log with spew after spew of exceptions, donkey!
Down with exception abuse. Down with try. Down with it all. If you really need to provide more information about the return type, use a tuple, or a class return type, or an output variable. Exceptions should be for exceptional incidents, not some bastardization of a normal return result. And this isn't even getting into how exceptions butcher performance. Bahhh!!!
(Score: 2) by Immerman on Thursday July 18 2019, @01:41PM
I don't think they're talking about adding exceptions though - go already has a second return value to communicate errors. What they're looking for is a way to get the simplicity and clarity of writing code like
try to do these things
Step 1
Step 2
Step 3
and if any of them return an error, immediately
Do whatever cleanup is necessary
I think this particular proposal amounts to having the cleanup be just "abort and return the error to the calling function"