Proof: Any exception system that lacked the ability to catch exceptions from lower frames would be called a defective exception system.

This check keyword does not implement an exception handling system.

That’s very different behaviour and along with using the error interface avoids the main objections to exceptions ( unexpected throws handled far from the error location, unexpected errr types).

This is just a small change to make it easier to annotate and easier to return without comment.

Is that a good thing?

Yes, because instead your program won’t compile if you forget to handle an error ( except in the case of a function which only returns error, which you can ignore by mistake - I would like to see that fixed in go 2 as well).

Sure. It's explicit error handling that just so happens to look exactly like a form of exception handling, c.f., the zero-overhead exceptions proposal in C++land.

This is how you say, in language-design-ese, "I want to do what my critics have been saying for years is the right thing without admitting that they've been right all along".

I saw a talk by James Gosling (of Java fame) a few months ago in which he said one of the most important things he's glad he did throughout the development of the language is "Decide... not to decide".

The purpose of this "deciding not to decide" should sound familiar by now: once you commit to something, it's hard to backtrack. And once it's hard to backtrack, you have lost your ability to look for more optimal solutions than the one you've fixated on.

This is why generics in Java took so long. And to this day, the developers of those generics do not regret taking their time to do so. I think that's interesting to note, don't you?

It's okay to make decisions after deliberation.

Deliberation does not imply a fight.

---

Tone police aside, did you... read... the proposals? I don't think it's correct to dismissively say that the proposed handle/check syntax is identical to other checked exception syntaxes; it doesn't compose in the same way as traditional try-catch blocks; and it doesn't have the power to create arbitrary longjumps across multiple stack frames as exceptions do. In short, it's very little like traditional exceptions at all.

If you just feel like snarking, then sorry for spoiling.

And to work around that problem, you need some kind of generics that lets you define error signatures in terms of other signatures - e.g. for map(), you want to say that it can return an error if and only if the function it maps can return an error (and ditto for error types).

  handle err {
          cleanup1()
          return 42, nil
  }
  handle err {
          cleanup2()
  }
  check dostuff()

  try {
      try {
          dostuff();
      } catch (Exception e) {
          cleanup2();
          throw e;
      }
  } catch (Exception e) {
      cleanup1();
      return 42;
  }