On Sunday, 5 June 2022 at 00:40:26 UTC, Ali Çehreli wrote:
[...]
> Errors are thrown when the program is discovered to be in an invalid state.

The following program throws an `Error` in popFront:

   import std.range;

   void main ()
   {
      int [1] a;
      auto q = a[1..$]; // line 6
      q.popFront;       // line 7, throws core.exception.AssertError
   }

When the program counter (PC) is at line 6 the program is in a valid state.

At no time the program is in an invalid state and it would not pass into an invalid state if popFront threw an `Exception` instead of an `Error`.

On 6/4/22 23:31, Ola Fosheim Grøstad wrote:
> On Sunday, 5 June 2022 at 00:40:26 UTC, Ali Çehreli wrote:
>> Errors are thrown when the program is discovered to be in an invalid
>> state. We don't know what happened and when. For example, we don't
>> know whether the memory has been overwritten by some rogue code.
>
> That is not very probable in 100% @safe code. You are basically saying
> that D cannot compete with Go and other «safe» languages.

I did not mean that. I think we have a misunderstanding at a fundamental level.

> Dereferencing
> a null pointer usually means that some code failed to create an instance
> and check for it.

Dereferencing a null pointer does not throw Error but fine. I agree.

>> What happened? What can we assume. We don't know and we cannot assume
>> any state.
>
> So D will never be able to provide actors and provide fault tolerance.

Let me show an example. Here is a piece of code that could be running in an actor:

struct S {
  int[] a;
  int[] b;

  void add(int i) {    // <-- Both arrays always same size
    a ~= i;
    b ~= i * 10;
  }

  void foo() {
    assert(a.length == b.length);  // <-- Invariant check
    // ...
  }
}

void main() {
  auto s = S();
  s.add(42);
  s.foo();
}

The code is written in a way that both arrays will *always* have equal number of elements. And there is a "silly" check for that invariant. So far so good. The issue is what to do *when* that assert fails.

Are you sure that it was a silly programmer mistake? I am not sure at all.

>> Is the service in a usable state?
>
> Yes, the actor code failed. The actor code change frequently, not the
> runtime kernel.

Is the only other culprit the runtime kernel? I really don't know who else may be involved.

>> Possibly. Not shutting down might produce incorrect results. Do we
>> prefer up but incorrect or dead?
>
> I prefer that service keeps running: chat service, game service, data
> delivered with hashed «checksum». Not all software are database engines
> where you have to pessimize about bugs in the runtime kernel.

There are also bugs in unrelated actor code writing over each others' memory.

It is possible that the service will do unexpected or very wrong things. But you answer my question: Your game server can do weird things. Hopefully all acceptable by paying customers.

> If the data delivered is good enough for the client and better than
> nothing then the service should keep running!!!

Yes! How can you be sure data is good when the silly assertion above failed. How could that happen? Is there any logical way to describe it was actor code's mistake? I don't think so. Let's assume the commented-out parts do not touch the arrays at all.

You are free to choose to catch Errors and continue under the assumption that it is safe to do so. The advice in the article still holds for me. I think the main difference is in the assumptions we make about an Errors: Is it a logic error in actor code or some crazy state that will cause weirder results if we continue. We can't know for sure.

>> I hope there is a way of aborting the program when there are invariant
>
> Invariants are USUALLY local. I dont write global spaghetti code. As a
> programmer you should be able to distinguish between local and global
> failure.
>
> You are assuming that the programmer is incapable of making judgements.
> That is assuming way too much.

I resent causing that misunderstanding. I apologize.

The only assumption I make about the programmer is that they do not mix Error and Exception so that in the end an Error points at a situation that warrants aborting the mission. Hm... Thinking more about it, assuming that an Error is due to a local programmer error would be a judgment.

Ali

On 6/5/22 04:43, kdevel wrote:
> On Sunday, 5 June 2022 at 00:40:26 UTC, Ali Çehreli wrote:
> [...]
>> Errors are thrown when the program is discovered to be in an invalid
>> state.
>
> The following program throws an `Error` in popFront:
>
>     import std.range;
>
>     void main ()
>     {
>        int [1] a;
>        auto q = a[1..$]; // line 6
>        q.popFront;       // line 7, throws core.exception.AssertError
>     }
>
> When the program counter (PC) is at line 6 the program is in a valid state.
>
> At no time the program is in an invalid state and it would not pass into
> an invalid state if popFront threw an `Exception` instead of an `Error`.

That looks like an argument for changing the behavior of D runtime when an out-of-bounds access occurs. Of course, it is too late to change that at this time but perhaps there can be a compiler switch like -boundstype=[error|exception].

The programmer has many options to prove that nothing crazy is happening. A common example suitable for many cases:

  enforce(!q.empty); // (Throws Exception)
  q.popFront;

Ali

On Sunday, 5 June 2022 at 14:24:39 UTC, Ali Çehreli wrote:
[...]
> struct S {
>   int[] a;
>   int[] b;
>
>   void add(int i) {    // <-- Both arrays always same size
>     a ~= i;
>     b ~= i * 10;
>   }
>
>   void foo() {
>     assert(a.length == b.length);  // <-- Invariant check
>     // ...
>   }
> }
>
> void main() {
>   auto s = S();
>   s.add(42);
>   s.foo();
> }
>
> The code is written in a way that both arrays will *always* have equal number of elements.

I think this is what Sean Parent called "incidental data structure" [1]. I would refactor the code:

struct T {
   int a;
   int b;
}

struct S {
   T [] t;

  void add(int i) {
    t ~= T (i, i * 10);
  }

  void foo() {
                // Look Ma no assert!
    // ...

  }
}

void main() {
  auto s = S();
  s.add(42);
  s.foo();
  s.a ~= 1; // does not compile
  s.foo();
}
```
[1] <https://www.google.de/search?q=incidental+data+structures>

On Sunday, 5 June 2022 at 15:07:13 UTC, kdevel wrote:
> ... I would refactor the code:

I really liked this one. The way it solves and at same time restrict the "external access" with that struct of (a,b) makes the code easier to maintain too.

Glad I keep lurking around this forum.

Matheus.

On 6/5/22 08:07, kdevel wrote:
> On Sunday, 5 June 2022 at 14:24:39 UTC, Ali Çehreli wrote:
> [...]
>> struct S {
>>   int[] a;
>>   int[] b;
>>
>>   void add(int i) {    // <-- Both arrays always same size
>>     a ~= i;
>>     b ~= i * 10;
>>   }
>>
>>   void foo() {
>>     assert(a.length == b.length);  // <-- Invariant check
>>     // ...
>>   }
>> }
>>
>> void main() {
>>   auto s = S();
>>   s.add(42);
>>   s.foo();
>> }
>>
>> The code is written in a way that both arrays will *always* have equal
>> number of elements.
>
> I think this is what Sean Parent called "incidental data structure" [1].

Like many other programmers who include me, Sean Parent may be right.[1]

Other than being a trivial example to make a point, the code I've shown may be taking advantage of the "structure of array" optimization. I am sure Sean Parent knows that as well.

> I would refactor the code:

Most likely me too.

> struct T {
>     int a;
>     int b;
> }
>
> struct S {
>     T [] t;
>
>    void add(int i) {
>      t ~= T (i, i * 10);
>    }
>
>    void foo() {
>                  // Look Ma no assert!

The assert may have been moved to another place:

struct T {
    int a;
    int b;

  invariant() {
    // Look Pa it's still here!
    assert(b == a * 10);
  }
}

Ali

[1] I stopped following Sean Parent when he dismissed D and me by waving his hand behind and walking away: "A language with reference types? No, thanks." That happened at the end of one of his presentations here at the Silicon Valley C++, which I happened to co-host. I am sure he is observant enough to one day realize that C++ has reference types by convention. (I recently posted links to C++ core guidelines proving that point of mine, one of which is something to the effect of "never pass polymorphic types by-value".)