In article <✉forums.inprise.com> Raoul De Kezel <✉hotmail.com> wrote:
> In article <✉4ax.com>, ✉eircom.net says... > > > There is no way we can predict beforehand that a network > > > connection or a target machine will break on next use. > > > Whatever the quality of the input data.... > > > > That information is external to the program, and enters it through > > function calls; thus, it is still input data. > > Barry, I'm afraid something is not getting through.
Yes. I lost the context of the thread, due to a problem with NTFS this morning; I only downloaded the latest 500 headers.
> I am trying > to say that checking at time T that a connection is alive wont > tell us anything about its state at time T + 1 microsec, when we > perform a write. > > Some faults just cannot be predicted. That's why the relevant field > is called fault tolerance and not fault avoidance.
But the problem can still be dealt with in a transactional style, yes? Exceptions provide a method of dealing with that.
Exceptions aren't a panacea; I'm not saying that they are the cure for all error conditions. I'm just trying to say that they're better than error codes for most classes of errors.
Most classes of errors. Not all.
-- Barry
-- 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