Google's Go team decides not to give it a try 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 …
Languages like Go, Rust and Swift have just decided on a simpler model than try / throw / catch. This was a conscious decision to avoid the complexity, cost and edge cases that exceptions have caused in other languages.
Instead these languages expect functions to describe errors through their interface and the immediate caller is expected to handle errors in the response. Go best practice uses multiple return values, the first being for success, the second for error. Rust has an explicit Result<S, E> generic. Swift's syntax superficially resembles try / throw / catch but it's much like the first two in practice - the "throw" is just returning an error that the immediate caller must "catch".
Rust and Swift have pretty well defined ways of doing error handling that doesn't make you miss exceptions at all in the real world. But it's a bit ad hoc in Go. I assume this "try" proposal was an attempt to make it easier and it put it on a more equal footing.
Personally I've never understood the point of 'try'.
To me it adds complexity - more keywords, more complex compiler/interpreter, etc.
Whats wrong with:
do something
if ( error ) {
handle error
}
or even simpler (of course depends on language)
do something || handle error
These seem easier, using keywords/structures that are used commonly in the code for all sorts of things, rather than introducing and learning a new construct/keyword for one particular purpose, handling errors, that can be done just as well with the existing constructs.
@eldakka said: "Personally I've never understood the point of 'try'. "
Exception handling is a feature that is very useful in certain types of applications. If you need to use it you really appreciate it.
Where it is especially useful is when you have a long sequence of things to do, each of which must be checked for errors, but where the exact nature of the error doesn't really matter in terms of what you will ultimately do about it.
If you check for errors through a series of "if/else" statements, then the code ends up almost unreadable and likely containing several new errors of its own.
With exception handling you put an exception block around the code that has to be checked and it bails out automatically for you without all the repetitive boilerplate. The code becomes much more readable as you can follow the main flow without getting tangled up in the error handling. It's particularly useful in libraries where you allow the exceptions to bubble up to the higher levels where they can often be handled more sensibly in the given context.
Without exception handling what tends to happen in practice is that people forget to check for errors, especially those rising up from lower levels, and the errors manifest themselves as crash reports from users.
There can be cases where manual error handling using if/else can be the better way, but not in most cases. I would compare it to automatic memory management versus manual memory management. The latter is better in some cases, but in most cases is a notorious source of bugs and memory leaks.
With 'C' exception handling is sometimes emulated using a programming convention that uses goto (yes, C has goto). I've used this convention in a few applications, but it's not as clear or as readable as actual exception handling.
So to sum up, "proper" exception handling is better at putting the programmer's intent clearly and concisely while being less prone to creating new errors because the intent is inherent in the syntax. There are many application domains where it is very useful and helps eliminate entire classes of common programmer errors.
"Personally I've never understood the point of 'try'."
It's one of those "the road to hell is paved with good intentions things".
For example Java exceptions aren't exceptional but everyday occurences. Things that are errors in other languages are exceptions in Java, e.g. file I/O. It's very easy to inadvertantly leave a file open until the next GC because a file was opened but not closed by a finally block after an exception. This antipattern is so common that the language was kludged with a try-using variation for things to be disposed of properly during exception handling. And it's not uncommon for functions to swallow exceptions whole rather than propogate them through their function definitions. Same for .NET.
C++ leans towards exceptions being truly exceptional but it has rules and caveats e.g don't throw in destructors and be careful of them in ctors because of unwinding issues. It's is never obvious whether something you call directly or indirectly is going to throw an exception so the control flow becomes unpredictable. Major libraries like QT don't even bother to use exceptions at all. Google's coding guidelines say not to use them either. The general rule is they're best avoided or just used in the main method just in case. Some software is even compiled with exceptions disabled.
I think the people who worked on Go, Rust, Swift have decided they're better off without this grief and have gone with something simpler.
This post has been deleted by its author
I have no interest in Go myself not being a developer. But after seeing what seems to be quite a number of articles and complaints from the Go community about google not agreeing to do stuff, I am curious how close is the community to forking the thing? Given it is open source(haven't checked what kind of license) I assume that is possible.
Excuse me but I'm a bit tired of the never ending cycle... Someone creates a language with a lot of powerful features designed to make developer lives easier. People then proceed to use those features, and unavoidably, some also abuse those features and create monsters. The next generation decides that it is better to not have these features than risk the chance of someone abusing them, so they remove them. Case in point: Rust and inheritance, and now Go
Now in a few years someone will realize the amount of extra code and effort that has to be added to Rust/Go programs to emulate those missing features, go back and add them in their next generation language. Only to have them abused and.... oh please. There is already enough experience in the usage patterns to know that the problem is most always not the language, but how the developer uses it and how change averse development can be without the right processes. Language designers: fix that, not what is not broken.
Go is designed to compile fast & run fast. By a language designer that is p****** *** at the way that languages have evolved for the last few decades.
Panic & recover were not part of the original spec. They could have yielded to the community and added try. Instead, they went with a borked half-implementation.
Having read some commentary on the topic, including this, it is my impression that what was being proposed was NOT a try/catch/finally structure. Instead, it was a method of making an early return from a function should some internal call go awry.
Perhaps my understanding of Go and the proposed try implementation leaves something to be desired. But if I read it right, their try implementation does little for error handling (it does provide an elegant syntax for error trapping). But it just shoves the error back up the calling stack with no explanations.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
