> Why else the "on E:<exceptionclass>"
> handling sub-statements. Why else a 'try' part at all, not just implicit
> coverage by the next downstream "except-end" block.
> Kristofer
>

Yes. That's kind of what's been running through my mind.  Were exceptions
just put there to perform the same function as a safety net for a flying
trapeze artist?  I doubt it.  That would a waste.   In mose cases, if a
routine exits unhappily and returns the user to the main program loop,
that's about as good as crashing and re-starting the program.  Who knows
what state the system is in?  And further, nothing alerted the user that the
system just croaked and (maybe) recovered.


I kind of had a feeling that I'd be starting a religious war with this
thread, but it has been quite educational to hear peoples' reasons.


The best arguments I've heard against using lots of exceptions are about
resource use.  Frankly, that logic doesn't sit well with me as resources and
speed seem to be less and less a concern.  Does anyone have any hard numbers
about added code size, execution size or speed?  I'd be interested in
hearing about that.


What it's boiling down to for me is:
What if I write a routine that returns an error code.  Someone uses it, but
doesn't handle the error code because "this is just a quick and dirty
version".  A lot of "quick and dirty" code is updated to shipping without
all the chances to catch errors being handled.  Exceptions seem the solution
to that.  If my routine raised an exception, and something went wrong, at
least the shipping code wouldn't go blindly on thinking that everything was
ok.


A programmer must explicitly dismiss an exception, while an error code can
be ignored by default.


-pete