4 ms·
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 er
by 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 agoThat is not the only difference. Exceptions travel through calling functions if there is no catch clause. The check construct does not.
- spullara 8y agoThe default handler just propagates the error up to the caller.
- ianlancetaylor 8y agoAnd 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 agoBut 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.
- ecnahc515 8y agoAn 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 8y agoWhat is an "unmarked check call"?
- erik_seaberg 8y agoWhen 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.