enforce()?

Lutger lutger.blijdestijn at gmail.com
Wed Jun 16 15:19:41 PDT 2010


Walter Bright wrote:

> Ary Borenszweig wrote:
>> On 06/16/2010 04:15 PM, Walter Bright wrote:
>>> The difference is not based on those 3 points, but on what Andrei wrote
>>> here. Contracts and error checking are completely distinct activities
>>> and should not be conflated.
>> 
>> Could you please explain them? There are many people here that don't
>> understand the difference between these two concepts (including me). So
>> maybe we are too dumb, maybe those concepts are not generally known or
>> maybe the explanation is not very well clear in the documentation.
> 
> It has nothing to do with being dumb, as it is not obvious.
> 
> Contracts are for verifying that your program is in a state that it is
> designed to be in. A contract failure is defined as a program bug.
> 
> Errors, on the other hand, are things that can go wrong at run time, like your
> disk is full when trying to write a file. These are NOT program bugs.
> 
> Another way to look at it is your program should continue to operate correctly
> if all the contracts are removed. This is not true of removing all error
> checking and handling.
> 
> 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. 

Suppose for example (actually this is from real life) there is an important 
operation which, as a service, also sends an e-mail notification as part of that 
operation. It is very bad if the operation fails, but a failed notification is 
not that bad. What to do in case of a bug with the e-mail notification?

1. crash (gracefully), do not complete the operation.
2. log the error for the devs to look into (or crash) *after* the operation is 
complete, let the operation go through without the e-mail notification.

Option 1 is annoying and prevents people from getting work done due to a 'minor' 
bug. Option 2 however probably results in this bug either not getting noticed 
quite early enough or ignored in the face of other issues that always seems to 
have higher priority. Choosing for option 2 can also lead to bugs being 
swallowed silently or mistaken for exceptional conditions, which is more 
dangerous.

I don't mean to split hairs, I bet a lot of software has these kind of cases.



More information about the Digitalmars-d mailing list