Sorry for the delay in responding to this thread - I've been traveling for the last week.
This whole discussion has me chuckling. Let's see if I can recap the essence of the discussion: - We like error codes because they are fast. - We hate exceptions because, having imposed all manner of extraneous feature creep on the exception mechanism, it's slower than molasses. Folks, the root problem with exception performance is not in any way inherent in exceptions. The root problems are (1) CLR did them badly, and (2) people keep insisting on features that impose a huge penalty. First, there is absolutely no need to create a new exception object whenever you throw an exception. The exception object can be constructed statically and a reference to it can be thrown. Returning that reference has identical cost to returning an error code. No, you won't get dynamic per-exception information, but you were perfectly willing to give that up by returning error codes, so why is everybody whining about that? Second, there is absolutely no need to copy stack frames when an exception is thrown. It is not a requirement that the stack remain immutable, and it is not a requirement that the stack be preserved from the originally thrown exception. You are only going to perform a backtrace for an exception that is *not caught. *In that case, no code has run that might modify the stack, and the original stack is alive and well. You can then perform a backtrace from there. All that is needed is to preserve the SP and PC from which the original throw occurred. Some of you have been imagining richer mechanisms than this, but once again you all seem perfectly willing to tolerate not getting those mechanisms in the error code style of design. Unwinding the stack until a catch handler is found is generally *cheaper* than conventional error return. Both mechanism are doing precisely the same thing; the error return case does it more explicitly, but that doesn't change the cost of it. Bennie notes that your map may change by DLL unload, but that's wrong. In order for that to happen, you had to hit a catch handler. At that point the original exception has been caught and you aren't ever going to see a stack trace from it. If a subsequent throw occurs, then it obviously can't be entangled with the DLL unload. So the real problem here isn't the inherent cost of exceptions at all. It's the cost of creeping featurism.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
