In article <3b7d8864$2_1@dnews> "Pete d'Oronzio" <✉pdmagic.com> wrote:
> > 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?
The programmer who wrote the rollback procedures, either explicitly with
try..except ... raise; end or implicitly with a try.. {commit}
finally..end block.
> 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.
I wouldn't want to be executing thousands of exceptions a second in a webserver, say.
> 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.
I agree with you. The main reason why I'm in favour of exceptions is the same reason I'm in favour of democracy; it's pretty miserable, but it's the best thing we've found so far.
-- Barry