Hacker News Reader

Comment by the_duke | Hacker News Reader

Edit: To clarify, the handle() system does indeed resemble an exception propagation system and is also the part I like least.

Just "check" would be preferable, with an implicit handler of "if err != nil { return err }"

Although I still would prefer something leaner like the "?" operator from Rust.

View on HN

One of the key characteristics of exception handling is the ability to set a handler in one stack frame, but receive exceptions from deeper in the stack, causing error-handling-at-a-distance. Anything that does not have that is not an exception system.

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.

This is the default behavior of the new check system. If you don't handle it at the bottom of the stack it is propagated up the stack to the caller automatically. Not sure how easy this will be to debug since it doesn't capture a stack trace at the bottom and it won't be obvious where the error started.

But isn’t it only to the immediate caller using the explicitly declared error, not all the way up the stack?

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.

Assuming the caller uses check as well it will continue on. Seems the same as checked exceptions to me.

That’s an invalid assumption, as most functions will not use check (looking at my code there are just a few places I’d use it). It’s an addition to current error handling, not a replacement.

Ok, we won't call them exception handlers. Instead, call them "if anything goes wrong in this function do this" handlers.

Those are very different things, whatever you want to call them. check/handle doesn't involve unwinding the stack, and doesn't default to crashing your program if you forget to add a handle block.

and doesn't default to crashing your program if you forget to add a handle block

Is that a good thing?

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

Expect to see a lot of `_, _ = fmt.Println(...)`, then.

Since they’re calling it go 2 perhaps they could just make an exception for println by having an alternative with no error (like map access with k,ok or just k).

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

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.

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.

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

If you are interested in learning why check-handle differs from traditional exception handling, you can read https://go.googlesource.com/proposal/+/master/design/go2draf....

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

Are there any write-ups on how your error handling proposal interacts with higher-order functions and generic wrappers? That has always been a problem with "explicit everything" approach to error handling, in my experience - like, if you map() over a collection that does disk I/O as part of its implementation, then map() needs to be able to flow I/O errors through - but it can't be aware of them specifically, because it's a generic algorithm. In Java, it pretty much meant that you had to use the RuntimeException escape hatch, defeating the purpose of checked exceptions. For another example, generic collection interfaces don't reflect the fact that e.g. fetching an item can fail, making them that much less generic.

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

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;
  }

That is not the only difference. Exceptions travel through calling functions if there is no catch clause. The check construct does not.

When every function call uses "check", we end up with the same control flow as exceptions, which is almost always what I want. You only get different behavior where you don't use it.

The default handler just propagates the error up to the caller.

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.

What is an "unmarked check call"?

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.

An unmarked check call would mean explicit error handling like if err != nil {} which isn't unchecked..it's just checked not using `check`. If you don't have this, then your error variable will be unused an you'll get a compile error.

Reply on news.ycombinator.com