Article

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

Re: Exceptions vs Error codes

In article <3b7cdabb_2@dnews>
	"Kristofer Skaug" <✉satserv.nl> wrote:

> "Barry Kelly" <✉eircom.net> wrote in message
> news:✉4ax.com...
> >
> > It depends on the quality of the input data. If it is user sourced, the
> > user should see the error. If it is highly desirable to continue at all
> > costs, error conditions should probably be determined before an
> > exception is raised.
> 
> Think of your application in the vertical way, composed of chains of
> functions calling other functions to get an ultimate task done. There is
> a reasonable likelihood that your lowest levels of code will consist of
> generic stuff (e.g. the Delphi RTL and WinAPI functions). When you use
> these functions to process input data, whether it's from a human
> operator, a network socket, other software (by e.g. COM), or a database,
> you should ideally speaking be completely aware of the "terms and
> conditions" for each of your library functions (input range, failure
> domain...). If this is well specified you also know exactly why it might
> fail and you can take the appropriate measures in pre-validation of data.
> If not (and you tell me how well specified the Delphi RTL is...) you are
> in trouble, and you need to protect with try-except.

Not try..except; try..finally. Perhaps the odd 

try except   // error condition clean up   raise; end;
where the situation warrants it.
> > Certainly, more work needs to be done on this area of data flow
> analysis
> > in compilers. Perl has an interesting mechanism called 'tainting'. You
> > should look it up.
> 
> Went to Perl.com and had a look. It might indeed be an interesting
> support option in OP to get a mapping of all variables under influence of
> external sources (note even subtle things like ShortDateFormat which can
> be changed by user from the Windows Control Panel...).

It requires some kind of rich data format, like Perl's scalars (pretty
similar to variants), because it is a run-time flag.

Perhaps most useful in critical applications, like security etc.
> > It depends on the routes by which information can enter the system.
> 
> That too, but like I said above also you have to be aware of how your
> code behaves, and 

> if you are not sure then that is the point to expect
> exceptions.

NO!! EXCEPTIONS CAN HAPPEN ***ANYWHERE***. 

You don't "expect exceptions", because the state "I don't expect any exceptions" *does not exist*.
I think one best appreciates exceptions when you look at how it (error handling) has to be done in the absence of them; return codes, global variables, etc. They can make code almost unreadable, and it requires elaborate manually-written rollback functions, which have to be checked themselves, and so on ad infinitum.
-- Barry
FYI: Phrase searches are enclosed in either single or double quotes
 
 
Originally created by
Tamarack Associates
Tue, 07 Feb 2023 05:59:43 UTC
Copyright © 2009-2023
HREF Tools Corp.