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

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

Yes. If someone is passing your email system a handwritten letter,
something is so wrong, the program should balk and exit. It's not just
a small mixup, it's an indication something is completely wrong.

As Walter put it, an Error, be it an AssertError or otherwise, means
your program has ventured into uncharted territory, and behavior from
this point on is undefined. "Permissible undefined behavior ranges
from ignoring the situation completely with unpredictable results, to
having demons fly out of your nose."[1]


-- 
Simen

[1] http://groups.google.com/group/comp.std.c/msg/dfe1ef367547684b?pli=1

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

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

Ah. Then no, handling the exception is perfectly acceptable, and probably
the right thing to do.

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

Yes and no. Throwing an error puts the program into an undefined state,
and everything may happen. Because everything happening at once would
strain space-time and cause Bad Things™ to happen, we would like to limit
the time in which this does occur. Hence, we bail out.

That said, a bug in a rarely-used function may indeed be significantly
less important than getting a server back online. However, I would still
say an error indicates something is fundamentally wrong.

-- 
Simen

On Wed, 16 Jun 2010 07:31:39 -0700, Andrei Alexandrescu wrote:

> Michel Fortin wrote:
>> On 2010-06-16 05:15:24 -0400, Walter Bright <newshound1@digitalmars.com> said:
>> 
>>> 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.
>> 
>> True.
>> 
>> Yet, enforce is inside std.contracts. If that isn't conflating the two concepts I wonder what it is. :-)
> 
> You're right! I think Lars' suggestion is sensible - we should move enforce to object. Better yet we should find a better name for std.contracts. Ideas?
> 
> Andrei


A few suggestions (even though I still think it belongs in object.d), in no particular order:

std.enforce
std.assumptions
std.constraints
std.checks
std.tests
std.error
std.errcheck

-Lars

On 16/06/2010 15:45, Andrei Alexandrescu wrote:
>
> Well throwif describes mechanism and enforce describes intent. After all
> assert is not abortif :o).
>
> Andrei

Indeed, especially given that other code program may use throwing as mechanism, but with a different intent. And you would not be able to distinguish it if you called it throwif.


-- 
Bruno Medeiros - Software Engineer

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

Simen kjaeraas wrote:
> Lutger <lutger.blijdestijn@gmail.com> wrote:
> 
>> 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?
> 
> Yes. If someone is passing your email system a handwritten letter, something is so wrong, the program should balk and exit. It's not just a small mixup, it's an indication something is completely wrong.
> 
	Bad example. If someone is passing bad input to your program, it
should signal the mistake and recover. External input must *always*
be checked and wrong inputs must be recovered from gracefully.

	However, if you take (and check) the user input, then put it in a
queue, then take things from the queue for processing, and you get a
handwritten letter out of the queue, *then* it is an error and
cannot be recovered from (because this should have been checked for
before putting the letter in the queue and if this is messed up, you
don't know what else may be messed up nor how bad the situation is).
Which is what you say after:

> As Walter put it, an Error, be it an AssertError or otherwise, means your program has ventured into uncharted territory, and behavior from this point on is undefined. "Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to having demons fly out of your nose."[1]
> 

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

Bruno Medeiros wrote:
> 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.

That's a reasonable way of looking at it.

Simen kjaeraas wrote:
> That said, a bug in a rarely-used function may indeed be significantly
> less important than getting a server back online. However, I would still
> say an error indicates something is fundamentally wrong.

The contract failing means you do not know what went wrong. That means there's no way the program can determine if it is recoverable or not. For all you know, malware may have infected your process and continuing to execute may send your credit card database to a thief.

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

On 06/17/2010 04:10 AM, Lars T. Kyllingstad wrote:
> On Wed, 16 Jun 2010 07:31:39 -0700, Andrei Alexandrescu wrote:
>
>> Michel Fortin wrote:
>>> On 2010-06-16 05:15:24 -0400, Walter Bright
>>> <newshound1@digitalmars.com>  said:
>>>
>>>> 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.
>>>
>>> True.
>>>
>>> Yet, enforce is inside std.contracts. If that isn't conflating the two
>>> concepts I wonder what it is. :-)
>>
>> You're right! I think Lars' suggestion is sensible - we should move
>> enforce to object. Better yet we should find a better name for
>> std.contracts. Ideas?
>>
>> Andrei
>
>
> A few suggestions (even though I still think it belongs in object.d), in
> no particular order:
>
> std.enforce
> std.assumptions
> std.constraints
> std.checks
> std.tests
> std.error
> std.errcheck
>
> -Lars

We haven't reached consensus on where to put enforce() and friends. Any other ideas? Of the above, I like std.checks.

Better yet, how about defining std.exception that includes a host of exception-related functionality (such as defining exceptions that retain file and line, perhaps stack traces etc.)?


Andrei