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.
--
Bruno Medeiros - Software Engineer
