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