In article <3b7932c6_1@dnews> "Kristofer Skaug" <✉satserv.nl> wrote:
> "Barry Kelly" <✉eircom.net> wrote > in message > news:0d2hnt09m4r82qfpokg5a1pt36jd86jn0b@ > 4ax.com... > > > > Please list some valid uses of > exception-swallowing try..except blocks, > > and I'll show you that the majority > should have checked for error before > > doing whatever raised the exception. > > > > I think it is fair to say that it > depends on how you specify a piece of > code. What should it do? under which > conditions should it fail or exit > abnormally? etc. IMO thorough > pre-validation of input data is > preferrable to relying entirely on the > occurrence of an exception.
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.
> This is > because, it is possible that the > function you call can return incorrect > results without any exceptions raised > (or other error information) if you feed > it unchecked input data...
That should not be possible; information entering the system should be checked as appropriate for its level of use.
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.
> and that > depends on how the lower level function > is specified, implemented and tested.
It depends on the routes by which information can enter the system.
-- If you're not part of the solution, you're part of the precipitate. Team JEDI: http://www.delphi-jedi.org NNQ - Quoting Style in Newsgroup Postings http://web.infoave.net/~dcalhoun/nnq/nquote.html