Comparing Exceptions and Errors

[Ali Çehreli]

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