On Wed, 22 Dec 2010 15:21:52 -0500, Rob <[email protected]> wrote:
Steven Schveighoffer wrote:
On Tue, 21 Dec 2010 17:16:57 -0500, Rob <[email protected]> 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
