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: 1) by khallow on Thursday July 18 2019, @12:13PM (3 children)
(Score: 2) by Immerman on Thursday July 18 2019, @01:36PM (2 children)
Except you can't. You can only return from the current function from within the current function. Moreover "boilerplate code" is rarely identical, which is what you need to stick it in a library. The general pattern of
if step 1 caused an error
Abort
if step 2 caused an error
Abort
//...
if step N caused an error
Abort
Is very common in a whole lot of different situations, where steps 1 through N are completely different
And some sort of language constructs that says
try to do these things
Step 1
Step 2
//...
Step N
and if there's a problem
Abort
saves a whole lot of redundant code that otherwise that both wastes programmer time to type, and decreases clarity when reading
In C you could do something like
if(Step1 == error
|| Step 2 == error
|| ...
|| Step N == error)
Abort
and rely ion the short-circuiting behavior to jump to Abort on the first error. You'll lose all information about what error occurred, but that often doesn't matter. But thanks to Go's multi-return error model I don't think there's a clean way to do that
(Score: 1) by khallow on Sunday July 21 2019, @03:41AM (1 child)
f := try {
Step 1;
Step 2;
Step 3;
...
}
(Score: 2) by Immerman on Sunday July 21 2019, @07:15PM
No, my impression (assuming I didn't end up following a link to some other proposal) was that the specific proposal was for something far less powerful or effective:
try(step1)
try(step2)
etc.
Where any failure would immediately exit the calling function with the same error. Honestly, I can't think why anyone thought that was a good idea.
Yours seems like a much better strategy to provide most of the benefit without significantly changing flow control, or being easily confused with a more typical exception-based try statement.
Of course it would typically need to be followed by an
if(f!= null){
//do error handling;
}
block, unless you also supported a catch block to replace the redundant test (since a conditional jump must have just occurred to exit the try). A catch with no "parameters" though would also be different enough to not be easily confused with another language.
And presumably, if you didn't actually care about what error is returned, you could simplify it a bit further by leaving out the f:= part. e.g.
try{
step1
step2
}
catch{
return ... , myError
}