Well, yes, but I would also argue that, in this particular case it's not only performance that is a concern but also complexity.
The fact that exception handling is generally expensive is hardly a justification for making it even more so. And even programmers who know so will continue to use expensive features which leads to a general degradation of the entire platform experience (cannonical Java example - Xerces library). >2) As far as I can tell, EXCEPTION_CONTINUE_EXECUTION requires filters. >This functionality is *very* nice to have, and while it is currently not >implemented, I'm pretty sure future versions will implement it. Maybe so, but I haven't seen an overwhelming number of cases where it is being used (actually, perhaps I don't all ten fingers to count how many times I saw it used.) Maybe you have seen good examples? >3) It maps nicely onto the Windows SEH implementation, but isn't very >portable to other OSses. It seems obvious to me that Microsoft would >consider both the former and the latter a plus ;-) Hmm... I'm not big on conspiracy theories and as a designer I doubt that would be a convincing argument.(wink noted) Cristian On Fri, 3 May 2002 10:25:14 +0200, Jeroen Frijters <[EMAIL PROTECTED]> wrote: >Cristian Diaconu wrote: >> I'm trying to understand the possible reasons why filters >> have been added to .NET. > >I guess it boils down to three issues (for me). >1) Is the performance difference between two-pass and one-pass relevant? >I would argue it isn't. Exception handling is expensive. Programmers >know that. Making it a little more expensive isn't that big a deal IMHO. >2) As far as I can tell, EXCEPTION_CONTINUE_EXECUTION requires filters. >This functionality is *very* nice to have, and while it is currently not >implemented, I'm pretty sure future versions will implement it. >3) It maps nicely onto the Windows SEH implementation, but isn't very >portable to other OSses. It seems obvious to me that Microsoft would >consider both the former and the latter a plus ;-) > >Regards, >Jeroen > >You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or >subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
