Hacker News Reader

Comment by throw_m239339 | Hacker News Reader

> Coming from assembly language, I always found the anti-goto sentiment rather cute. A beautiful restriction, but ultimately arbitrary. Like writing poetry. Or those novels that do not ever use the letter "e". Why would an otherwise sane person write code with "rep" and without ever using "jmp"?

There is no need to use GOTO when a language has functions/procedures and exceptions.

Of course it makes sense in Assembly or more rudimentary languages, or in specific cases for speed optimization (getting out of multiple loops).

However, I must admit, sometimes I'm sick of the way Go "deals" with errors so I resort to GOTO to manage HTTP errors in my HTTP request handlers.

View on HN

One thing a C-like goto has over exceptions is that you can only jump around within a single lexical scope. That restriction is a big win for readability.

Exceptions use a dynamic scope to decide where to jump to, so, in the general case, it's a lot harder to understand how they will affect program behavior by simply reading the code. That's a major reason why using exceptions for non-exceptional control flow is widely considered to be evil.

> There is no need to use GOTO when a language has functions/procedures and exceptions.

There is no need for exceptions either. Everything can be done with error code.

Just because there are redundant mechanisms to achieve same result does not mean one of them must be abolished.

> There is no need to use GOTO when a language has functions/procedures and exceptions.

The usual example of when goto saves more trouble than it causes is breaking out of a nested loop early. You can avoid goto in that scenario with a sufficient number of flags, but flag-heavy code tends to be harder to read than a couple apposite gotos. Even better is Perl-style named blocks, though.

> There is no need to use GOTO when a language has functions/procedures and exceptions.

... and defer

> and defer

Which “defer”? The go panic/defer pair is, while structured differently, functionally equivalent to exceptions.

You use exceptions to clean up resources even when there are no errors? Why?

You don't need to use exceptions for that, but a finally block, something like this:

  try { ... }
  catch (SomeException e) { ... }
  catch (SomeOtherException e) { ... }
  finally { /* cleanup code */ }

Pretty much every language with exceptions has an equivalent of that finally block, a portion of code guaranteed to run whether there is an exception or not.

Defers in Go act like that finally block, but permit you to attach them at the point where the initialization they clean up was written. This can help with longer code blocks, but it's fundamentally the same as the above (with or without the catches). So if you use defer (the following is not really Go, but captures the idea):

  function echo_file (filename) {
    f = open(filename);
    if nil == f { return; } // simple error handling, just don't do anything
    defer close(f);
    for line in f {
      print(line);
    }
  }

  function echo_file (filename) {
    f = open(filename);
    if nil == f { return; }
    try {
      for line in f {
        print(line);
      }
    }
    finally {
      close(f);
    }
  }

The former is much shorter and clearer, especially for straightforward cleanup code, but is the same as the latter in what it does. Whether an exception or panic occurs during the read/print loop or not, the file will always be closed in both cases.

> You use exceptions to clean up resources even when there are no errors?

exception handling mechanisms (try/except/finally) are idiomatic for that in languages with them (try/finally, particularly, because it assures cleanup whether or not an unhandled exception occurred); defer offers equivalent power with slightly different structure; you don't need both for any purpose either will do.

Reply on news.ycombinator.com