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.