Bruno Medeiros <brunodomedeiros+s...@com.gmail> wrote: > On 17/06/2010 00:27, Walter Bright wrote: >> Lutger wrote: >>> Walter Bright wrote: >>>> Furthermore, errors are something a program can recover from and >>>> continue >>>> operating. Contract failures are ALWAYS fatal. A common newbie (and > > > > some >>>> expert) misconception is that contract failures can or even must be >>>> recovered. >>>> This comes from a misunderstanding of the basic principles of >>>> engineering a >>>> safe and reliable system. >>> >>> I am not so sure about this last point, usually you want to fail but >>> perhaps not always. This is about what to do after detection of a >>> program bug vs how to handle an exceptional condition. >> >> First you need to decide if it is a program bug or not. If it is not > > a >> program bug, it shouldn't be done with contracts. >> > > I would go further and state that anything outside the direct control > of a process (such as network state, disk state, OS state, other > processes behavior, user interaction, etc.) should be modeled as an > error and not a contract violation. > Such externals errors may be a "bug" in the system as whole, but they > are not a bug in the particular process, and thus should not be > modeled as a contract violation. > In other words, _contract violations should always be situations that > you can prevent by changing the code of the underlying process_. You > can't do that for network errors, disk state, etc.. But you can do > that for stuff like ensuring a variable is never null, an object in > your program is in some particular state at a particular point in > execution, etc.
Right. I'd say contracts are to catch logic errors.
