It is worth noting here that its exceptionally slow in Debug mode ( may be a factor of 10^5 to 10^6 slower) , in release mode its not too bad... but its certainly not fast . In debug mode its almsot cerainly building the stack address via reflection etc and VS debugger may get in there as well. In release mode you could do 300K- 1M fail / catch exceptions per second but is that needed ? Is it good programming ? Thats what tryparse type methods are all about. Its kind of anoying too , sometimes i like to check thrown exceptions in the debugger and when you have exceptions for logic you loose that abbility.
Ben On Tue, Jul 30, 2013 at 8:23 PM, David Jeske <[email protected]> wrote: > 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. > > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
