AF Style Question

[CaseyM]

---

@AristosQueue (NI) wrote:

... especially when any error returned ought to stop the actor.

---

Could you explain why (or point me to documentation if it already exists) this is the thinking?

In my experience, this default behavior is one of the top points of confusion when someone is starting with AF. I think most developers would expect an error to be displayed or logged rather than the actor simply stopping without the error being "handled" at all.

[Dhakkan]

---

@CaseyM wrote:

---

@AristosQueue (NI) wrote:

... especially when any error returned ought to stop the actor.

---

Could you explain why (or point me to documentation if it already exists) this is the thinking?

In my experience, this default behavior is one of the top points of confusion when someone is starting with AF. I think most developers would expect an error to be displayed or logged rather than the actor simply stopping without the error being "handled" at all.

---

The closest I could find in the past was this post by Allen Smith. I bookmarked another discussion thread, very informative and helpful at least for me, here. One of the posts in that thread links back to the one pertaining to Allen's post.

[CaseyM]

Thanks. That's helpful.

[AristosQueue (NI)]

---

@CaseyM wrote:

---

@AristosQueue (NI) wrote:

... especially when any error returned ought to stop the actor.

---

Could you explain why (or point me to documentation if it already exists) this is the thinking?

In my experience, this default behavior is one of the top points of confusion when someone is starting with AF. I think most developers would expect an error to be displayed or logged rather than the actor simply stopping without the error being "handled" at all.

---

I wrote the framework, and in the early days, in 0.x drafts, we tried variations on error handling patterns. The problem is this: most actors aren't top-level actors. And if their job is to display the error or log the error, then they should do that and not return the error. But we couldn't add generic "log this error" everywhere because many low-level errors have no business polluting a general log file... they need to bubble up through the ranks to become meaningful in the context of the application as a whole.

> rather than the actor simply stopping

> without the error being "handled" at all.

You miss the key: stopping IS handling.

When an actor returns an error from any of its Do methods, it is literally saying, "I could not Do." There's no general recovery state. Some actors may be able to recover for some specific subset of errors, but a general recovery isn't well defined. It's equivalent to throwing an exception in C#/C++/Java... that low level process halts, tosses its error up the chain, and the caller (in Handle Last Ack) says, "Oh, I see the problem because I have greater context." The caller can then decide to fix the problem and re-launch the actor (because the final nested actor state is included in Last Ack), log/report the error, or throw it further up the chain. The handling is the chain of actors until it gets to someone who knows how to truly react to the error. Note that I use the term "react" and not "handle" -- handling errors is an over-broad term for a wide range of actions that include propagating the error up to a more competent scope.

People who say that actors should log the error or "handle" the error in a generic way are generally only thinking of top or near-top actors that represent the bulk of the application. But the vast majority of actors are well below the water level of the application iceberg. 

My presentation at the GDevCon NA last week actually touched on this -- it was all about error propagation and suggestions for improving how the G community thinks about errors moving through a program. I didn't discuss Actor Framework at all in that presentation, but if you happen to see the video (they're posted [or will be] somewhere on GDevCon NA site), you could apply some of the lessons I highlight in that presentation to the Actor Framework.

Does that help?

[AristosQueue (NI)]

PS: if you want to report an error to the caller but not halt your nested actor, you should be sending a message to caller that says, "I had an issue but I'm able to continue operating, but I recommend logging this error." Maybe call it "Report Issue Msg" or something. The caller can then consider whether or not your actor is actually one that should be logging in the context of the current application and, if so, log it (or pass it along higher if that actor itself is not one that is doing logging).

You can give every actor in your system access to the global log file, and there are good reasons to do that, but every large app I've worked on eventually ends up with a useless log file because deep level functions are logging things that are pure noise from the overall system. Some mechanism for escalating and optionally logging based on a system configuration "detail level" is generally more helpful in my experience.

[CaseyM]

---

@AristosQueue (NI) wrote:

---

Does that help?

---

Yes, thanks for the context and, in light of that, the decisions make sense. I guess my follow-up question would be, "Is there a way to make this less confusing or more obvious for new AF users (that haven't taken the NI training)?"

I don't have any good answers right now - I'm just trying to think of ways to make AF more inviting to new users. Or am I the only one who has seen confusion over this behavior?

[CaseyM]

---

@AristosQueue (NI) wrote:

PS: if you want to report an error to the caller but not halt your nested actor, you should be sending a message to caller that says, "I had an issue but I'm able to continue operating, but I recommend logging this error." Maybe call it "Report Issue Msg" or something. The caller can then consider whether or not your actor is actually one that should be logging in the context of the current application and, if so, log it (or pass it along higher if that actor itself is not one that is doing logging).

---

Yes, I've generally done this via a "Process Error" message that is included in a base actor that does pretty much what you describe.

[Taggart]

---

@CaseyM wrote:
I'm just trying to think of ways to make AF more inviting to new users. 

Good luck.

[t.kendall]

After taking the AF class from Allen Smith, working with AF for two+ years it took an expert joining our team for six months to really clean up and change the way we were coding.  Now it is kind of shocking to compare the actors written before and after they were on our team, we have gone from using ActorCore for everything to majority 'on the wire' actors. 

The learning curve could be better for sure. A specific error vs warning example might be helpful. 

[BertMcMahan]

---

@t.kendall wrote:

After taking the AF class from Allen Smith, working with AF for two+ years it took an expert joining our team for six months to really clean up and change the way we were coding.  Now it is kind of shocking to compare the actors written before and after they were on our team, we have gone from using ActorCore for everything to majority 'on the wire' actors. 

The learning curve could be better for sure. A specific error vs warning example might be helpful. 

---

I agree, I've been using AF for a few years, but as a solo dev it's easy to just get set in my ways. There isn't a lot of practical info on best practices out there. Lots of the examples are so simple they're basically worthless to do anything other than showing how actors work. Others are so abstract as to be nearly useless for newbies (like most discussions about message brokers that I've seen). Last, there are lots of abstract discussions that, while good in theory, have little to say when it comes to actual implementation. I find myself getting "stuck in the weeds" at times when I try to learn something new, and it's a grueling process to do by yourself. Oftentimes the overarching principle is quite clear but getting from "general SOLID principle" to "working code" is, for me at least, quite hard!

At least most people on the boards are quite willing to answer questions 🙂

And in that vein... could you comment more on an example where you went from using Actor Core to doing things in messages? I too use Actor Core quite a bit, though usually it's because I need a GUI with an event handler.