Hi, What I was trying to make clear was that I have no control over (some aspects of) this. I have to use the .NET exception handling facilities and I'm stuck with its (in)efficiency.
Regards, Jeroen > > -----Original Message----- > From: Mark Wielaard [mailto:[EMAIL PROTECTED] > Sent: Friday, March 14, 2003 21:03 > To: Jeroen Frijters > Cc: Archie Cobbs; [EMAIL PROTECTED]; Prof. Etienne M. Gagnon > > Hi, > > On Tue, 2003-03-04 at 09:57, Jeroen Frijters wrote: > > Archie Cobbs wrote: > > > Here's another slant on this idea: if you don't care > about the stack > > > trace, there's no reason an exception object can't be > reused. So the > > > native code could just keep around a pre-allocated > exception object > > > and throw it over and over again as necessary. > > > Since it's always caught, it will never "escape" into any > code that > > > could try to print out its stack trace. > > > > Just to point out that not all VMs are the same, on ikvm > throwing an > > exception will always cause a stack trace to be built, I > cannot avoid > > that, because that is just the way the underlying platform > (.NET) works. > > But as Archie points out in some cases you really are not > interested in getting the stack trace. For example if you > come across the following > code: > > try > { > doSomething(); > } > catch (Throwable t) > { > // Ignore exceptions fall back on default. > doSomethingElse(); > } > > At the beginning of the try-catch block you know that any > exception thrown in the block will never get used. So what > you can do is set some Thread local flag that can be checked > later when a Throwable is created that is about to get thrown > (but never used for something else). The flag gets cleared > again when you drop out the try-catch block. Then when you > actually have to create and throw an exception and the flag > is on you just skip the whole java exception object creation. > > Of course it gets interesting if the code doesn't catch > Throwable but e.g. IOException and if these things get nested > but I am sure something could be worked out for those cases > by using a stack that remembers the most specific exception > that will be ignored next and you problably have to benchmark > some programs to see how often this pattern occurs and and > which situations doing all the bookkeeping is just overhead. > There must be papers about such exception elimination techniques. > > Cheers, > > Mark > > _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
