On Tue, Jul 30, 2013 at 5:23 AM, David Jeske <[email protected]> wrote:
> 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. > That is an interesting and productive observation. The intent of *finally* clauses was to mitigate this, but it isn't clear that they are effective at doing so. Do you have any thoughts on how code path duplication of this form might be avoided? > 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... > That's only true because you are looking at selected cases that have limited environmental dependencies and can therefore be specified with relative confidence and completeness. Looking at procedures in the IO portions of the libraries tends to give a different outcome to the analysis. The error handling mechanism, whatever it may be, has to work for both scenarios. > (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. > Hmm. So my problem with this is that I *lived* through the history you are describing. I had occasion to wrestle with it as one of the SVR4 developers. Your description is simply wrong. Any library function is entitled to modify errno. I agree that a change in status (as to whether errno is modified) breaks both the API and the ABI. Much worse: it breaks them *silently*. Nonetheless, it can and has been done. AT&T had a Change Review Board partly because the impact of this kind of thing is potentially bad. The job of the CRB was to determine whether the benefit justified this disruption. The CRB was never more conservative than when faced with a problem that silently breaks an API/ABI. DEC had a similar process for VMS. But these situations are real. They happen, and they can't always be avoided. Ultimately, it's a human judgement call to decide what to do about them. And once again: the *reason* that declared exceptions failed in Java is that the space of exceptions *does* need to expand over time. That situation is much more murky with existing implementations of > exceptions. The routing of runtime exceptions into an unsuspecting call > stack is unpredictable. > I'm sure you are saying something useful here, but I can't work out what it is. It seems to me that the routing of exceptions up the call stack is quite clear. For example, the triggering of destructors in C++ is quite clear even when a completely unknown exception traverses the stack. The unclear part is where a previously unknown (or at least unknown to the calling developer) may get caught. I'm pretty sure that I am not understanding what you mean by "routing" here. Can you explain? > > 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. > Oh dear. Yes. That would certainly do it. It's one of the places where dynamic introspection incurs a *very* high price. > 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. > Yes. The stack-based security model of both CLR and JVM is boogered in too many ways to count. This is certainly one of them. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
