Article

From:
To:
Kristofer Skaug
Subject:
Re: Exceptions vs Error codes
Newsgroup:
borland.public.delphi.objectpascal

Re: Exceptions vs Error codes

> 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
FYI: Phrase searches are enclosed in either single or double quotes
 
 
Originally created by
Tamarack Associates
Wed, 09 Oct 2024 17:06:39 UTC
Copyright © 2009-2024
HREF Tools Corp.