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.

Lutger <lutger.blijdestijn@gmail.com> wrote:

> 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.

How did you end up with an email system that is so horribly broken that
it spits Errors instead of Exceptions when things are not quite the way
it wants them to be?

If it cannot send the email, it may throw an Exception. If you try and
pass it a handwritten letter, it should throw an Error.

Basically, throwing an Exception means 'Your attention please, reactor 5
has a cooling problem you might want to look at', whereas an Error means
'Explosion imminent, get the fuck off outta here!'.

-- 
Simen

Simen kjaeraas wrote:

> Lutger <lutger.blijdestijn@gmail.com> wrote:
> 
>> 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.
> 
> How did you end up with an email system that is so horribly broken that it spits Errors instead of Exceptions when things are not quite the way it wants them to be?

Not Errors, it is not in D and does not distinguish between Errors and Exceptions. It was an example, a (design) question. It's very simple:

sendEmail() // possibly die here because something relatively unimportant thing is buggy

vs:

try
{
    sendEmail()
}
catch(BadShitThatCanHappen)
{
    RecoverFromBadShitThatCanHappen() // ok, this is good and according to spec
}
catch(Exception ex)
{
    logError()
    // now crash? assume we know this must be programmer's fault
}

> If it cannot send the email, it may throw an Exception. If you try and pass it a handwritten letter, it should throw an Error.
> 
> Basically, throwing an Exception means 'Your attention please, reactor 5 has a cooling problem you might want to look at', whereas an Error means 'Explosion imminent, get the fuck off outta here!'.
> 

No, an Error means the program has a bug. Programs have thousands of bugs, this is not related to how critical it is. An Exception can be way more important to fix than a bug. WebServerDownException for example, is often not a bug in the code that drives websites, but for sure I will contact the sysadmin before even thinking of going back to work. The question is how to proceed after the fact.

Simen kjaeraas wrote:

...
> If it cannot send the email, it may throw an Exception. If you try and pass it a handwritten letter, it should throw an Error.
> 

This is the question: should I segfault on a handwritten letter even if it is not such an important letter and could just go on operating?

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.

If it is a program bug, then the only proper thing to do is exit the program. The program cannot decide if it is a minor bug or not, nor can it decide if it is recoverable. It is, by definition, in an unknown state, and continuing to execute may cause anything to happen. (For example, malware may have installed itself and that may get executed.)

If you need notifications that the program failed, a separate monitor program should be used. This is how people who design safe systems do it. People who believe that programs can "recover" from bugs design systems that fail, sometimes with terrible consequences.

My articles on the topic:

http://www.drdobbs.com/blog/archives/2009/10/safe_systems_fr.html

http://www.drdobbs.com/blog/archives/2009/11/designing_safe.html

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.
> 
> If it is a program bug, then the only proper thing to do is exit the program. The program cannot decide if it is a minor bug or not, nor can it decide if it is recoverable. It is, by definition, in an unknown state, and continuing to execute may cause anything to happen. (For example, malware may have installed itself and that may get executed.)

I didn't really get this point from your articles on the subject, but that does clarify it for me. The assumption one makes when recovering is that it is indeed possible and safe. Even if it may be likely, it is never reliable to count on it.

Lutger wrote:
> The assumption one makes when recovering is that it is indeed possible and safe. Even if it may be likely, it is never reliable to count on it.

Exactly.

On 2010-06-16 14:59:45 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> Michel Fortin wrote:
>> On 2010-06-16 14:44:29 -0400, Michel Fortin <michel.fortin@michelf.com> said:
>> 
>>> On 2010-06-16 14:10:17 -0400, Jonathan M Davis <jmdavisProg@gmail.com> said:
>>> 
>>>> I would point out that pretty much nothing in std.contracts actually relates
>>>> to contracts. Rather, it relates to error handling. So, it would probably be
>>>> a good idea to simply rename the module - perhaps to std.error.
>>> 
>>> I concur: the module is misnamed. The only things not related to error handling are assumeUnique and assumeSorted, and I fail to see the link with design by contract for either one.
>> 
>> Oh, forgot about "pointsTo" too. What's the link with contracts, or error handling?
> 
> Certain functions (notably swap) must make sure that there's no mutual aliasing between two objects.

Ok, so you're using "pointsTo" to check this in a contract? But isn't that just a utility function which can be used for contracts as much as for everything else? Does it really belong in std.contracts because at some place you use it in a contract? I don't think so. But that's something for you to decide. And unfortunately I'm not sure where you put it.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 2010-06-16 20:45:47 -0400, Michel Fortin <michel.fortin@michelf.com> said:

> Ok, so you're using "pointsTo" to check this in a contract? But isn't that just a utility function which can be used for contracts as much as for everything else? Does it really belong in std.contracts because at some place you use it in a contract? I don't think so. But that's something for you to decide. And unfortunately I'm not sure where you put it.

Should have concluded by: "I'm not sure where you *should* put it either."

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 06/16/2010 11:44 PM, 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.

Ah, ok, now I understand. Thanks.