try...catch slooowness?

[Steven Schveighoffer]

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, but not expected.  For instance, an  
I/O error is not *expected*, but it is anticipated as possible if say the  
config file is not readable, but it's not expected to happen for a normal  
operation.  In this case, the exception most likely kills the program  
(can't do much without a config), but the program handles the error  
gracefully and prints a readable message rather than just "Broken Pipe" or  
something like that.

-Steve