4 ms·

> The draft design introduces two new syntactic forms. First, it introduces a checked expression check f(x, y, z) or check err, marking an explicit error check.

> The draft design introduces two new syntactic forms. First, it introduces a checked expression check f(x, y, z) or check err, marking an explicit error check. Second, it introduces a handle statement defining an error handler. When an error check fails, it transfers control to the innermost handler, which transfers control to the next handler above it, and so on, until a handler executes a return statement. 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".

heavenlyhash 8y ago
I really don't know where people get on this high horse and imagine that there's been some kind of fighting attitude here. 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.
- pjmlp 8y ago
  Actually they do, hence the ongoing work to add value types and reified generics to Java, which is again a multi-year project with no defined end date.
  - heavenlyhash 8y ago
    Sure, but just like there's a difference between "deliberation" and "a fight", there's also a difference between "hmm, there's more to do" and "we regret the thinking we invested so far".
rsc 8y ago
If you are interested in learning why check-handle differs from traditional exception handling, you can read https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf.... If you just feel like snarking, then sorry for spoiling.
- erik_seaberg 8y ago
  It looks like the only difference is that catch blocks precede try blocks and aren't indented to show how they nest. One could mechanically convert handle err { cleanup1() return 42, nil } handle err { cleanup2() } check dostuff() into try { try { dostuff(); } catch (Exception e) { cleanup2(); throw e; } } catch (Exception e) { cleanup1(); return 42; }
  - ianlancetaylor 8y ago
    That is not the only difference. Exceptions travel through calling functions if there is no catch clause. The check construct does not.
    - spullara 8y ago
      The default handler just propagates the error up to the caller.
      - ianlancetaylor 8y ago
        And then the caller has to either check or ignore the error. The error never propagates to the caller's caller without an explicit action in the caller. That is unlike exceptions.
        quotemstr 8y ago
        But it will propagate through a chain of unmarked check calls. If the requirement to mark potentially-throwing call sites is what disqualifies an error handling scheme as belonging to the class of exception systems, then we need a new term that includes both exceptions and this proposal and excludes everything else, because the proposed Go scheme very closely resembles exceptions.

heavenlyhash 8y ago

I really don't know where people get on this high horse and imagine that there's been some kind of fighting attitude here. 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.

pjmlp 8y ago
Actually they do, hence the ongoing work to add value types and reified generics to Java, which is again a multi-year project with no defined end date.
- heavenlyhash 8y ago
  Sure, but just like there's a difference between "deliberation" and "a fight", there's also a difference between "hmm, there's more to do" and "we regret the thinking we invested so far".

rsc 8y ago

If you are interested in learning why check-handle differs from traditional exception handling, you can read https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf.... If you just feel like snarking, then sorry for spoiling.

erik_seaberg 8y ago
It looks like the only difference is that catch blocks precede try blocks and aren't indented to show how they nest. One could mechanically convert handle err { cleanup1() return 42, nil } handle err { cleanup2() } check dostuff() into try { try { dostuff(); } catch (Exception e) { cleanup2(); throw e; } } catch (Exception e) { cleanup1(); return 42; }
- ianlancetaylor 8y ago
  That is not the only difference. Exceptions travel through calling functions if there is no catch clause. The check construct does not.
  - spullara 8y ago
    The default handler just propagates the error up to the caller.
    - ianlancetaylor 8y ago
      And then the caller has to either check or ignore the error. The error never propagates to the caller's caller without an explicit action in the caller. That is unlike exceptions.
      - quotemstr 8y ago
        But it will propagate through a chain of unmarked check calls. If the requirement to mark potentially-throwing call sites is what disqualifies an error handling scheme as belonging to the class of exception systems, then we need a new term that includes both exceptions and this proposal and excludes everything else, because the proposed Go scheme very closely resembles exceptions.