Oh well... it seems like there's no way to ask a question without it's
meaning being high-jacked :-)
Ted, I don't believe either Don or myself ever argued that using
exceptions for flow of control is an acceptable practice. I can't read
Don's mind, but as for myself, I promise you I don't do it even when
nobody's watching :-).
Second, nobody is "blaming the tool for their problem" like you said
either. This is *by no means* the intent of my question. I tried to keep
it as cool and factual as possible.
But picture this for a second:
You are one of the original designers of .NET and you have the option of
adding a feature that you know will have performance repercussions. You
also know for a fact that some people, either through ignorance or their
malignant nature, will misuse this particular feature. My question was
what are therefore the overwhelming reasons that still persuade you to go
ahead and implement the said feature? Are there any more reasons than the
obvious ones that meet the eye?
So the focus of my interest is not .NET bashing, but simply trying to test
my understanding of a design decision from the point of view of the
original designer, *not the user*.
I could have asked the same as it relates to Win32's SEH as well, but
that's not the point of this forum and in the case of Win32 no language
generic appeal was being sought. .NET appeals to language interop so
obviously I assume that filters must be useful in other languages that I
haven't heard of. If so, what are those languages/circumstances that
require it?
Thanks
Cristian
On Fri, 3 May 2002 13:11:03 -0700, Ted Neward <[EMAIL PROTECTED]>
wrote:
>That's sort of like saying that "you can't guarantee that violence isn't a
>standard practice for resolving conflict; however dubious you personally
may
>feel it is, this is a standard technique for many people". Just
because "it
>happens" doesn't mean we shouldn't try to STOP it. :-)
>
>The fact is, if they want to engage in dubious practices, then they pay
the
>penalty for doing so. In this case, the penalty is decreased speed and
>performance. They want to improve the speed, they need to come into line
>with how the tool's supposed to be used. Let's not blame the tool and/or
>platform here for what's essentially their problem!
>
>Ted Neward
>{.NET || Java} Course Author & Instructor, DevelopMentor
>(http://www.develop.com)
>http://www.javageeks.com/tneward
>http://www.clrgeeks.com/tneward
