News for hackers. Stuff that matters.
Re:Go 2 Draft Designs by jerf on Tuesday August 28, 2018 @01:04PM (#17860548)
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.

Re:Go 2 Draft Designs by spullara on Tuesday August 28, 2018 @02:48PM (#17861665)
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.
Re:Go 2 Draft Designs by grey-area on Tuesday August 28, 2018 @03:07PM (#17861875)
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.

Re:Go 2 Draft Designs by spullara on Tuesday August 28, 2018 @03:58PM (#17862325)
Assuming the caller uses check as well it will continue on. Seems the same as checked exceptions to me.
Re:Go 2 Draft Designs by grey-area on Wednesday August 29, 2018 @03:05AM (#17866290)
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.