Hi Ken, Your response assumes that programmers write code the way they are "supposed" to, i.e. you're assuming something code that simply may not be valid in practice. On a platform like .NET you can't guarantee that na�ve programmers won't use exceptions for control, e.g. raise an exception if an element isn't found in the domain of a dictionary and then catch it to go look somewhere else.
I will take a bet that no matter what is "supposed" to happen, there will still be many programs running on CLRs that use exceptions for control. However dubious you personally may feel it is, this is a standard programming technique for many people. Cheers, Don -----Original Message----- From: Ken Alverson [mailto:[EMAIL PROTECTED]] Sent: 03 May 2002 04:40 To: [EMAIL PROTECTED] Subject: Re: [DOTNET-ROTOR] [OT] double-pass exception semantic - Why? > From: Cristian Diaconu [mailto:[EMAIL PROTECTED]] > Posted At: Thursday, May 02, 2002 11:18 PM > Subject: [OT] double-pass exception semantic - Why? > > Against 1. The cost of handling every exception is *in theory* twice the > cost it would have been if filters would not have existed. It is important > to emphasize the difference between theory and practice and I'll get > back to that in a second. The point of exceptions is they are only supposed to happen in exceptional conditions. This means the speed of the exceptional case should not be important as long as the common case (non-exceptional) is fast. As far as I can tell, two-pass exception handling doesn't have adverse effects on the common case performance, so speed arguments are a red herring. Ken
