Error case in actor methods that should be called by message (style question)?

[Taggart]

---

@mthimm wrote:

---

---

Do you agree, that messages called by actors should be atomic transactions? 

---

Isn't that the whole point of a batch or calling a method inside a message rather than sending it as another message to yourself?

---

@mthimm wrote:

---

---

I have the feeling, that I block my actor uneccessarily if I do a direct call.

---

Not if you are direct calling a method that corresponds to a message, it shouldn't.  Ideally any method that corresponds to a message should be "non-blocking" and execute as quickly as possible.

---

@mthimm wrote:

---

---

  If you use an error case there you check in each call if no error is an error. This in my opinion is unnessecary. I doubt, that this is optimized by the compiler.

---

It's a simple boolean check.  Yes it may end up happening a lot but unless you have very high performance specs, I doubt it makes a difference in most real-world applications.  Maybe someone out there has done some testing to prove one way or another?

[mthimm]

There are two questions I have to answer, if I have to make a design decision:

1. Does it harm?

2. Is there need to do this?

You just answered the first question: It does only little harm. I agree with this. There is only one boolean per method to check and atomic transactions are supposed to execute very quickly. Something that is also a disadvantage to me, is, that I have different mechanisms to call the method. This might not be a disadvatage for everyone.

Nevertheless also small amounts add sometimes up, as we know from calculus. If your methods become more complicated and you make use of loops, if you have hardware timeouts and slow reacting hardware, things can add up in an evil way. I admit, that they should not add up since actors are supposed to be as simple as possible.

For me the answer to the second question is: No, there is no need, I even do not see an advantage. I have a priority queue which is a queue of queues and the responsibilties of me, my caller and my subactors should (this is not always achievable) be disjoint sets. So I can control the order of mixing methods that operate on the actor if I must. In addition this does not happen often and if there is need I always try to find a more robust solution (like delegating to a subactor).

When I started this thread I thought, that most people would agree that you should not do direct calls of such methods and wanted to know what people think about the error case structure inside such methods since there is unreachable code. I was wondering why the automatic generation of a static/dynamic dispatch method always includes an error case although (for me) a majority of methods are called by messages. Unreachable code is only a style issue it does only little harm.

[Taggart]

I can see why you would want to get rid of it.

I do believe all the project provider scripting tools are unlocked.  You could just edit those.

[drjdpowell]

---

@mthimm wrote:

When I started this thread I thought, that most people would agree that you should not do direct calls of such methods and wanted to know what people think about the error case structure inside such methods...

---

It's quite easy to assume other people have the same mental model about how to do things.  The things one considers most important are the same things one thinks are obvious and don't need to be stated.  So it is good to investigate whenever something someone else has designed doesn't seem to make sense, even if it is an unimportant detail, as it is a clue to differences in mental model.  And that can help one to understand, more explicitly, the rules that one has been intuitively following.   My various discussions with AQ and other AF users over the years have helped me to better understand the rules I use with my own "Messenger Library" framework.

[Taggart]

There are always many different ways of thinking about the problem...

[mthimm]

---

drjdpowell wrote:

It's quite easy to assume other people have the same mental model about how to do things...

---

This is not a problem for me, I still find the discussion interesting although it became unexpected. I appreciate your contributions as well as those from other people. The goal of discussion for me is to improve my understanding.

The question wether to place or not to place unreachable code is not a mental model. My mistake was not to believe, that somebody could make a portion reachable with (probably) only little harm and no need.

But this can be easily fixed by coding (or style) guidelines that forbid such modifications. I am in charge to define guidelines, when I hand over projects to my colleagues and I have the possibility to propose guidelines, when I get projects handed over. So I will keep this in mind.

Since you had lots of discussions with the creator of AF and a lot of much more experienced AF users than me over many years and since you have created your own actor model based messenger library I would be interested in your opinion about putting an error case, if modification of the according do.vi is not allowed.

In addition I would like to know what you would do, if you override an method. Do you put the error case manually, in front and behind the parent call?

What is about your Library, is there a possibility to change the messages execution on message level? I like in the automated AF message that the coding of the do.vi and the coding of the message action itself are done separately, although all do vi.s look very similiar. I find, that this is a good example of clean code and separated responsibilities. But you would allow to mix them, am I right?

[drjdpowell]

---

@mthimm wrote:

---

@drjdpowell wrote:

It's quite easy to assume other people have the same mental model about how to do things...

---

This is not a problem for me, I still find the discussion interesting although it became unexpected.

---

It's a problem for everybody.  Discussions often become unexpected because they revel that others have different ways of thinking.

---

But this can be easily fixed by coding (or style) guidelines that forbid such modifications. I am in charge to define guidelines

---

People won't follow your guidelines unless they understand your mental model and buy into it.

In addition I would like to know what you would do, if you override an method. Do you put the error case manually, in front and behind the parent call?

I don't generally use "error cases", and instead I chain the error wire through all functions.  In the case of a parent call, one should generally call the parent so it has the chance to execute any action that it needs to do even on error in (clean up code and the like).

---

---

I like in the automated AF message that the coding of the do.vi and the coding of the message action itself are done separately, although all do vi.s look very similiar. I find, that this is a good example of clean code and separated responsibilities. But you would allow to mix them, am I right?

Interesting you bring up "separated responsibilities".   By requiring all actions in handling a message to be done in the Actor method and not in the Message Do.vi seems to me to NOT be separating responsibilities and would be less "clean".   Things that are the natural responsibility of the original message sender are forced into the message receiver.  This was an issue in a recent conversation here about Request-Reply.