enforce()? (what should be a contract)

[Sean Kelly]

Bruno Medeiros <brunodomedeiros+spam at 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.