try...catch slooowness?

[Steven Schveighoffer]

On Wed, 22 Dec 2010 15:21:52 -0500, Rob <rob2970 at yah00.com> wrote:

> 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).

Sorry, I guess I dummer than you.

-Steve