back to article 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 …

  1. Jedihomer Townend

    “If or if not. There is no try.” - Yoda

    1. RyokuMas Silver badge
      Coffee/keyboard

      God dammit...

      See icon.

  2. Anonymous Coward
    Anonymous Coward

    panic and recover functions.

    Why panic and recover?

    The whole world knows the format and syntax of

    try {

    something

    }

    catch (some sort of exception e) {

    }

    Why is that so hard?

    1. desht

      Re: panic and recover functions.

      Sounds like a severe case of NIH, to be honest.

    2. Filippo

      Re: panic and recover functions.

      I don't know Go and I was a bit weirded out by this as well when I read the article. My first thought was that maybe they did it to discourage using exception handling for non-exceptional cases, which is generally considered poor practice.

    3. SVV Silver badge

      Re: panic and recover functions.

      You'll have to wait until they invent Go++

    4. Anonymous Coward
      Anonymous Coward

      "The whole world knows the format and syntax of"

      You still need the "finally"....

    5. DrXym Silver badge

      Re: panic and recover functions.

      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.

    6. eldakka Silver badge

      Re: panic and recover functions.

      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.

      1. thames

        Re: panic and recover functions.

        @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.

        1. swm Bronze badge

          Re: panic and recover functions.

          At Xerox most of the copier code was in error recovery - not the "main line". Error code needs to be able to be written simply - not necessarily the "main line" code.

      2. DrXym Silver badge

        Re: panic and recover functions.

        "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.

        1. swm Bronze badge

          Re: panic and recover functions.

          When writing an operating system I realized that there were NO errors. Disk errors, funny status returns etc. are normal and have to be handled. Throwing an error to someone else that doesn't have a clue about the details wouldn't work.

  3. AMBxx Silver badge
    Joke

    On error GOTO

    Need a specification for a spoof language - GOTO, GOSUB, case sensitive for confusion, loosely typed like Javascript. Strings half objects, half not.

    1. Pascal
      Joke

      Re: On error GOTO

      "On Error GoTo" is boring.

      "On Error Resume Next" is where the real fun is.

    2. desht

      Re: On error GOTO

      If we're adding GOTO, then I suggest the COMEFROM counterpart is also required.

    3. Psmo Bronze badge
      Angel

      Re: On error GOTO

      If we're looking for new language features and metaphors maybe the following?

      On Frisbee error_treatment() Dog error_handling_fails()

      1. Ordinary Donkey
        Pint

        Re: On error GOTO

        On Error Pub

    4. wikiwikiwika

      Re: On error GOTO

      So, the language you are looking for is Visual Basic?

  4. Starace Silver badge
    Alert

    xkcd.com/927/

    See above.

    Yet another go at reinventing the wheel, then trying to make it like the other wheels that already work.

    1. Amentheist

      Re: xkcd.com/927/

      use strict;

      use warnings;

      use Try::Tiny;

      ^ that's my non-Go crutch, the rest is ofc voodoo. But in a way it does make sense to keep the core clean

  5. Nate Amsden

    fork it?

    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.

  6. SecretSonOfHG

    Going full circle?

    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.

    1. Claptrap314 Silver badge

      Re: Going full circle?

      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.

  7. Claptrap314 Silver badge

    We polled everyone who drank our koolaid...

    They said it tasted good.

  8. Paul Hovnanian Silver badge

    try, no catch

    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.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019