try...catch slooowness?

[Rob]

Steven Schveighoffer wrote:
> On Tue, 21 Dec 2010 17:16:57 -0500, Rob <rob2970 at yah00.com> wrote:
>
>> Walter Bright wrote:
>>> Michel Fortin wrote:
>>>> Exceptions are slow, that's a fact of life. The idea is that an
>>>> exception should be exceptional, so the case to optimize for is the
>>>> case where you don't have any exception: a try...catch that doesn't
>>>> throw. Other ways to implement exceptions exists which are faster
>>>> at throwing (setjmp for instance), but they're also slower at
>>>> entering and exiting a try..catch block when no exception occur.
>>>
>>> [...]
>>>
>>>> Exceptions are recommended to avoid cluttering your normal code
>>>> flow with error handling code. Clearly, in the code above
>>>> exceptions are part of the normal code flow. That's not what
>>>> exception are made for.
>>>
>>> Right on all counts. Exceptions are for *exceptional* cases, i.e.
>>> unexpected errors, not normal control flow.
>>
>> Exceptions (actual ones and not just a reference to any particular
>> error handling mechanism) are EXPECTED errors. That follows directly
>> from the goal of keeping programs running by handling of errors that
>> were thought about at design time. Show me an unexpected error and
>> I'll show you a bug.
>
> No they aren't.  They are anticipated,

That is how the term "expected" is used in the literature. Read up. No 
need to play semantical/literal games. It's the concept that is relevant. 
The point is that saying that exceptions are unexpected is incorrect by 
just about any paper, article or book on error handling, save for those 
that get that wrong also (A. Andrescu's early book gets it wrong also, as 
I recall, FWIW).