enforce()? (what should be a contract)

[Bruno Medeiros]

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