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

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


Kristofer