Go Abandons try() Function Proposal, Citing 'Overwhelming' Community Response (theregister.co.uk) 124
Google's Go programming language will not add a try() function in its next major version, "despite this being a major part of what was proposed," reports the Register:
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.
There was therefore a proposal to add a built-in try function which lets you eliminate many of the if statements and triggers a return from a function if an error is detected. The proposal was not for full exception handling, which is already present in Go via the panic and recover functions. That proposal has now been abandoned. Robert Griesemer, one of the original designers of Go, announced the decision in a post Tuesday...
"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."
There was therefore a proposal to add a built-in try function which lets you eliminate many of the if statements and triggers a return from a function if an error is detected. The proposal was not for full exception handling, which is already present in Go via the panic and recover functions. That proposal has now been abandoned. Robert Griesemer, one of the original designers of Go, announced the decision in a post Tuesday...
"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."
Re:Java flashbacks... (Score:5, Informative)
Re:Java flashbacks... (Score:4, Interesting)
Where a simple if statement would have sufficed, and could have corrected the issue to allow processing to continue, no error checking is done at all because the whole thing is encompassed in a try catch that is several layers up in the call stack. That try catch can retry the calls that led to the exception, but often times it just aborts. Leaving cryptic error messages if anything about what went wrong.
Sounds like Common Lisp designers really had all the good ideas with conditions and restarts. Let's see when the rest of the world rediscovers *those*.
Common Lisp was a big step forward (Score:4, Informative)
And C was a huge leap backwards.
Common Lisp actually enabled the catch to interact with the throw routine, including to tell the throw to continue. The stack was simply not unwound until the catch was done. That meant you could throw warnings like low memory as well as throwing fails.
It would appear from Stroustrup's paper: http://www2.research.att.com/~... [att.com] that C++ added them without any knowledge of Common Lisp. And got it wrong.
In C++ the stack is unwound early, and you do not even get a stack trace by the time the Catch happens. An absolute pain. Almost better off with C style ERROR macros.
Java was created by Lisp men (Guy Steele) and introduced garbage collection to the unwashed masses. However the then come up with "checked" exceptions which encouraged exceptions to be ignored.
Re: (Score:2)
Strange, I never ran into a issue with the "try" operator. I have seen a lot of poorly written "catch" blocks
You would have had issues with the proposed try keyword in Golang, because it had nothing to do with exceptions, and was completely counter-intuitive.
Re:Java flashbacks... (Score:4, Insightful)
The "try" operator in Java never worked well. No reason to make the same mistake in Go.
On the contrary, the try statement and exceptions have worked well in many languages for decades.
Error codes could be, and frequently were, ignored. Exceptions cannot be.
Error codes led to long chains of error handling intermixed with the code for the normal flow of control, decreasing readability. The code for handling exceptional cases can be segregated.
Error codes require effort in each method to communicate failure up the stack. Exceptions don't.
Error codes cannot be easily communicated by functions in languages without pass-by-reference. Exceptions can be.
"All of the people, all of the time" (Score:2, Interesting)
The conclusion here is that developers really, really don't like try catch blocks. And this is probably a learned response because for upwards of 20 years, try catch blocks have been advocated by experts and included in virtually every CS curriculum going. This is one instance where you can't accuse a popular decision of being "uneducated" or "ignorant" of the the topic.
Exceptions have been abused with abandon by certain developers, and others have been left to deal with the consequences of that fallout for
Re:"All of the people, all of the time" (Score:5, Informative)
In Go, a function can have multiple return arguments, oftentimes the last return argument being an error object. It's a best practice that whenever you invoke a function that can return an error you check if there's an error set, and handle that, e.g.:
foo, bar, err := foobar()
if err != nil {
return fmt.Errorf("foobaring faied: %s", err)
}
A while ago, a survey was published where 6% of respondents said that error handling could/should be improved. This was subsequently interpreted as 'we need a syntax that allows for less lines than currently required. Besides the proposed syntax, that basic premise was discussed as well. Currently, native errors don't have e.g. stack traces etc, the survey didn't differentiate any further, so it's hard to conclude if one or the other should be improved.
Re: (Score:2)
Can you or someone familiar with the arguments against explain them? As far as I can see this makes a lot of sense.
Re: (Score:2)
Why not deal with all possible result states equally??
Because all possible result states do not occur equally and you're writing inefficient code.
Re:"All of the people, all of the time" (Score:5, Insightful)
I really can't agree with your post. As a veteran software developer who has maintained legacy code for a long time, I have found try/catch blocks essential to making the software robust. Proper logging within the catch blocks does worlds for helping the first tier tech support figure out what is wrong.
I have not found the try/catch structure to be problematic, nor does it make the code unreadable and hard to maintain, as you claim. I HAVE found that poorly-done object oriented design makes the code an utter mess. Many developers who insist they understand the right way to code to an interface just wind up inserting multiple layers of abstraction that aren't needed and require you to wade through three to four times as many files as you otherwise would in order to follow execution and get your head around the code. They do NOT "keep it simple," and that is what makes the code unmaintainable.
Try/catch blocks help keep the code simple, and I prefer them over using many branches for error checking.
Re: (Score:3)
I don't know what reality you live in, but in the really real world software runs into problems. If the error message can help first tier support resolve the issue without kicking me out of bed then I think it's doing it's job just fine. Maybe the software you write is error free and has the complexity of "Hello World" but the rest of us have to deal with software that is a tad more complicated.
tiers of essence (Score:2, Insightful)
You've vastly overstated "essential". What you mean here is "essential" in the absence of another viable method.
Not only is this idiom non-essential, it isn't even the best idiom for writing robust code.
Dijkstra explained this long ago. There is no such thing as an error. There are only things you can legally do and things
Re: (Score:2)
As someone pointed out, the author is a javascript weenie.
Re: (Score:1, Interesting)
I wonder what the next software concept revolt will be against? OOP? Agile? Build systems? The Cloud?
Agile is no longer a software concept. It is now a management concept. I have never worked in a single agile environment that seemed to care at all about how Agile affected people below a certain level of management. 45 minute daily standup with 15 ppl? Sure why not? Doesn't waste management's time. Incredible rate of bug growth because no one with intimate knowledge of the code base has the allowance to think more than 2 weeks ahead? You bet. Agile is a perverse management practice and an absolute cancer.
Re: (Score:2)
Re: (Score:1)
Re: (Score:3)
Agile is not a joke. The thing is nobody "uses" it. In fact, when people say they are "using Agile", that's a sign they simply don't know what Agile is. It's not a method of writing software. It's a philosophy that should inform the way you produce software. SCRUM is not Agile. SCRUM is a process for developing software. SCRUM was not informed by Agile; it can't be because it was invented before the Agile manifesto was published. If you rigidly adhere to SCRUM, you are probably not being Agile.
Re: (Score:2)
I worked at a place that used their own version of Agile for development of new projects. What a nightmare. They would go off and ask the client what they wanted. Then about a month later the first version was ready with what they thought the client wanted. The client would provide some feedback on how they got it wrong and in two weeks the next version would show up after massive changes to the whole design and architecture. Repeat and repeat and repeat ...
The problem was that they refused to sit down with
Re: (Score:2, Insightful)
The conclusion here is that developers really, really don't like try catch blocks.
What an odd conclusion. I'm a developer, though not a Go developer, and I LIKE try/catch blocks. Sometimes multiple things REALLY has to happen, and if it fails, we have a problem.
You sound like a black/white thinker. It either has to 100% solve the problem, or it's bad. Try/Catch is a tradeoff, like any other. It' a tool that you have to know how to use. Does the fact that some people miss-used try/catch mean that nobod
Re:"All of the people, all of the time" (Score:5, Informative)
The conclusion here is that developers really, really don't like try catch blocks.
Okay, hold up there. You can't draw this conclusion from the actual discussion. This proposed addition to Go was never about adding try/catch blocks. Go already has a similar concept called panic/recover.
The proposal was to allow changing this:
into this:
and that's it. There is no transferring of control to another block of code in the current or a parent function. The idea wasn't liked for a few reasons, but mainly because it hides the "return" keyword, so it's less clear that control flow is changing.
Re: (Score:2)
The conclusion here is that developers really, really don't like try catch blocks.
Not really. The conclusion is that a vocal minority don't really like try(). I'm willing to bet if you did a census of developers you'll find an overwhelmingly positive opinion of a feature used in many languages.
Exceptions have been abused with abandon by certain developers
10 Come up with irrelevant statement.
20 Post on Slashdot
30 GOTO 10.
Every language feature can be abused.
Academia can't fix it. Conference talks can't fix it. Media articles can't fix it. Books can't fix it.
Of course not. There's nothing that actually needs to be fixed. If you think you can eliminate poor developers somehow I try(sell bridge).
Re: (Score:2)
Re: (Score:1)
Exactly. Exceptions are bad because they screw up everyone else's code and the only fix is to wrap everything you didn't write with ugly boilerplate to prevent hard crashes. And all because the upstream library raises exceptions on bad mixing of language encodings that 99.99% of people doing text parsing will have something in THEIR code that fixes THEIR specific needs when it comes to bad data.
Similar to goto, perhaps Exceptions should be considered harmful and only used when it's absolutely the best way t
yeah sure because error ahndling before was fine (Score:2)
Re: (Score:2)
The experiment has failed.
Academia can't fix it. Conference talks can't fix it. Media articles can't fix it. Books can't fix it. Overburdened developers can search for "exceptions" and find everything from articulate blog posts to expletive laden Youtube videos giving voice to the frustrations of three generations of working professionals, who are tired of the failed projects, morasses of code, and undebuggable core dumps out in the real world, all consequences of flawed ideologies of software development.
I willing to be educated in the contrary. But do you remember what there was before try/catch and exceptions?
You say that your program failing with an Exception was bad. But I remember when the program didn't fail at all. It just kept chugging along corrupting my data. Debugging that was WAY worse than seeing an exception in my code. Forcing well defined crashes in programs has been very helpful during the las 20 years. In the previous 20 I remember lots of ignored errors, lots of return codes not checked,
Re: (Score:1)
The problem is the language not providing the tools you need. Exceptions are a loaded gun pointed at the head of your program and you have no idea where they are going to come from, if any will at all. Failure to check return codes is the end programmer's fault and they'll learn sooner or later. Failure to catch exceptions is everyone's problem. If any dependency anywhere in your project throws exceptions, now EVERYONE needs exception handling code and I bet none of the code your project depends on has any.
Re: (Score:2)
Yes. Failure to check return codes may be the programmer's fault, but other developers on the project get sloppy. In languages that properly support exceptions, nobody can ignore the exceptions. The exceptions can be handled globally for the most part anyway. Unfortunately code is written by teams and its often hard to enforce good practices, even moreso if you add external libraries. Exceptions have made things much better.
Your example about C++ kind of proves my point. C++ a language known for the innumer
Re: (Score:2)
Can anyone here who is a Go aficionado explain why this language is used at all? I admit, I've only looked into it briefly, but ... the part where you had to implement 3 separate methods to sort an array by a custom comparison function had me belly laugh heartily and never look at it again.
I've never used Go, but is this something that you have to do, or is it just a good idea to make a generic sort function that can be used regardless of array type? It seems to me that having the ability to write highly reusable code in a language is a desirable property and something that you'd want developers to know about.
Re: What is the appeal? (Score:3)
No, you do not have to do that. Here's an example of a custom comparison function to sort a list of strings by the second character:
a := []string{"afoo", "bbar"}
sort.Slice(a, func(i, j int) bool { return a[i][1] a[j][1] })
The inline function syntax is slightly verbose, but not terrible considering you need to write types.
Re:What is the appeal? (Score:5, Insightful)
As far as the main arguments people are probably giving ("With Java, it's compile once and run anywhere!") , Go and also apparently Swift seem to be claiming fill a niche that lies in-between scripting languages and C/C++/Obj-C. I'm not altogether convinced this niche is worth filling, or that Go fills it particularly well given the prior existence of powerful and fast compiled languages (like, say, the ML and Lisp families), but it has the "modern" features and hype machine behind it, plus the requisite C++/Java familiarity, so ok, whatever. (I think Rust looks a lot more interesting on paper, but Rust isn't meant to be a Go killer, it's meant to be a C++ killer.)
As for the syntactic sugar and comparison to older languages de jours, when Go first appeared on the scene I found it interesting to read about the "Go vs. Brand X" comparison [cowlark.com] (spoiler alert: brand X is one of the Algols; I forget which.)
Re: (Score:2)
Re: (Score:2)
Swift is definitely not there to fill a niche between scripting and C/C++/Objective C. Swift is there to replace C/C++/Objective-C at least in the context of application programming. I believe Go attempts to do the same thing for just C. I can't speak to Go, but Swift does a pretty good job except in terms of outright speed.
Re: (Score:2)
That's kind of like pointing out the fact that a Geo Metro does a pretty good job replacing a top fuel dragster in any aspect except outright speed.
Re: (Score:2)
I would note
Re: (Score:2)
but Swift does a pretty good job except in terms of outright speed.
Speed, and readabliity, and outright lack of cruft.
People complained that Objective-C had all the baggage of C, so Apple responded with a language that has the baggage of C and objective-C. Well done (golf clap).
Re: (Score:2)
A lot of "real" programmers continue to miss the fact that the majority of programming is done by non-programmers using code to apply their expertise from other domains.
I once saw someone who had invented their own else "design pattern" in VBA because they weren't aware of it. Using GOTOs. It was actually fairly well written code, but the person who'd written it was apparently wholly unaware of the existence of an else. Didn't know w
Re: (Score:1)
Better commodity code (Score:1)
Go doesn't really replace, e.g., C#. But while C# is elegant and powerful, it also enables bizarrely-cryptic statements using abstraction, inheritance, lambdas, delegates and more in ways that can result in inscruitable and unmaintainable code. You can do amazing things, but as a manager or lead, you often have to be vigilant against devs being too terse and increasing subsequent brittleness.
What Go replaces is, for example, Node.JS. It's very fast, very easy to write well, gives you a lot of power but
Re: (Score:3)
That's not surprising, Rust is a toy language, built by people who did not understand C++.
It will take them 20 years to slowly copy over all of the C++ features they're still lacking once they figure out they're actually useful.
Re: (Score:2)
Does std::unique_ptr have semantics anywhere near those of Rust mutable references?
Re: (Score:2)
That's not surprising, Rust is a toy language, built by people who did not understand C++.
As a C++ programmer, I say please don't be a dickheady C++ evangelist.
Panic is half way between std::abort (which is not catchable either) and exceptions. Slightly different choices doesn't make rust a "toy" language.
Re: (Score:2)
Re: (Score:2)
Access control without friend is just incomplete.
There is no... (Score:3)
Your moment to shine has finally come.
Re:There is no... (Score:5, Funny)
There is no try, there is only if and panic.
Re: (Score:2)
"Your code should alway be written to handle ALL possible situations, and treat them equally as normal states. To code for an idealized world ... is just bad programming."
Yet ironically what you advocate is exactly that - an idealised program for an idealised world. In the real world errors can't be handled like AnyOtherState because they're not , they're errors and require special attention and special code.
Perhaps when you've left college and worked in the real world you'll understand.
Re: (Score:2)
If your college doesn't teach you that you can't anticipate every possible situation then it's time to find a new college.
Re: (Score:2)
Re: (Score:2)
This is actually my favorite feature about Rust. It won't compile successfully until every single return value is handled at some point in the call chain.
Generally it takes longer getting new code to compile but once it does it tend to have fewer defects and require less debugging, both of the kind you see immediately and the hidden kind some user will suffer years later. Nothing is perfect ofcourse, you still have to review, test and debug thoroughly, but it helps a lot.
In my decades of C and C++ I've see
Stupid (Score:2)
Design by comittee (Score:2)
Of course, a try() operator is a good idea. It offers an alternative to the way this is done now and, in some situations, it will be superior. But apparently, some people feel threatened by more ways to do a thing. And apparently, Google has no idea about real-world language design and gave in to pressure from the masses.
Well, Go is not really useful for most things anyways. Far too limited and far too specialized to the containerized model.
Re: (Score:2)
The problem with their attempt was that the developers lost some functionality with the implementation. Doing things the current way someone could handle the error in a way that met their needs (log it, return it or an error message, etc).
Google would have been better off implementing a try-catch functionality. (If my code is wrong don't criticize as I've never programmed in Go before. It's an example to show how to keep the functionality.)
f := try(os.Open(filename)) catch (error) {
return fmt.Errorf("Open file %s failed: %s", filename, error)
}
Re: (Score:2)
The messed with previous behavior? That is not a good idea either. Sure, Google itself probably has the resources to change all their code, but other users may not. In that case, I retract my statement. Never break compatibility unless you absolutely have to. (Of course, that assumes a good design to start with. If you do not have that, you will need to break compatibility time and again and the whole thing may be better of scrapped in the first place.)
function modLanguage() (Score:5, Funny)
try { to implement a new construct. }
catch { shit for doing so. }
finally { just give up and use C++. }
This try is not like a Java / C++ try (Score:1)
Basically the proposal was to formalise the concept that if a function returned a success / error tuple, that try would test for error and return the error value, otherwise take the success value.
Given how ad hoc error handling is in Go, this seems like a useful thing. Other languages like Rust and Swift have far better error handling and its thought out and purposeful.
Re: (Score:2)
Given how ad hoc error handling is in Go, this seems like a useful thing.
This is a good start to solving the problem, but it only solves one subset of the problem. If they want to use the 'if' style of error handling, and replace it with helper functions, they need to create a system that handles all the common error cases, not just one of them. Here is a list:
1) A function that returns on error (which this does, which is less useful).
2) A function that prints an error and returns on error.
3) A function that prints a stack trace and returns on error.
Actually there are more
But but but but ... (Score:2)
Every Star Wars fan knows: "There is no try."