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