On Tue, 21 Dec 2010 17:16:57 -0500, Rob <rob2...@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
