I will accept your view on the performance of Liskov-exceptions vs propagated return values.
My criteria here is merely that I think slow structured error signaling mechanisms are a mistake. They are admitted under the notion that exceptional conditions are rare, but they force us to duplicate our codebase into two paths, convenient-slow-structured-errors and fast-unstructured errors. --- I don't think this look at errno is representative of typical C return-value error handling is fair. If I call snprintf, or strcpy, or and number of other stdlib calls, I know what failure modes they have, and those failure modes are undisturbed over time (whether by mechanism or convention) If a function has no error output parameter, it has no means to add error return in the future (other than exit(1), and divide by zero). This pattern extends into user-authored C today. Functions do not all return int because of some UNIX errno history. That situation is much more murky with existing implementations of exceptions. The routing of runtime exceptions into an unsuspecting call stack is unpredictable. Further, there is something which feels incompatible about current stack unroll propagation and handling generic errors with catch-all try blocks. Downstream code expects to throw exceptions through intermediate callers, so how do those intermediate callers handle binary success/fail in the next immediate level? In practice, good modules derive their errors from a base-error-class, making it possible to catch immediate module errors, while allowing downstream errors (such as network IO errors) to propagate through to higher level handlers. I do agree this is a good pattern. However, I wish for greater reliability that a binary success/fail try block will catch all of a modules errors without inadvertantly catching other errors. > It's an interesting question why the CLR exception mechanism is so slow. Do we have any insight into the cause? I *believe* this is an implementation defined issue related to preservation of exception source stack frames for reflection and stack back traces. As such, I *believe* a different implementation could allow runtime disable of unroll backtrace frame capture for faster unroll performance. However, I could be wrong. CLR uses stack walking as part of their security mechanisms, so that might be related. I don't know anything about callback exceptions crossing the kernel stack. >> Google-Go: has no stack-unroll exception mechanism, instead relying on error-return-values and the backward-compatible zero-as-success-value test. Google-Go meets both criteria (a) and (b), though it is unfortunate that so-far it offers no compiler assistance to assure exhaustive error-condition checking as in (zz). It also carries all the > > Can you finish that last sentence at your convenience? ... it also carries all of the syntax-overhead of C style error handling, rather than providing some more convenient syntax akin to try/catch. I personally feel the #1 benefit of try/catch is assistance in making code easier to read, by allowing us to simplify or move error handling clauses. The #2 benefit is compiler knowledge of the assignment validity of other "out" or "ref" return values. IMO, both of these benefits are orthogonal to, and can be provided without stack-unroll. I don't understand why Go didn't include them even if it chooses not to include stack-unroll.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
