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.
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.
ianlancetaylor|7 years ago
quotemstr|7 years ago
ecnahc515|7 years ago