Error handling in actor handle functions

[cdbennett]

What is the right way to handle errors in Ractor handler functions?

For instance, if an actor's handle() method is making I/O calls or other fallible operations, can handle() return an Err Result? If so, what happens? It seems like the actor panics and is killed, then when someone tries to send it a message later, they get the error result Messaging(ChannelClosed).

I have a couple of questions related to this:

• Should handle() be able to use the try-operator (?) or not?
• I am new to the actor pattern, but is letting actors be terminated if they raise an error result considered to be the normal way of handling things? I can see it would be useful in some situations to simplify robust error handling, but perhaps it's a bit too aggressive?

It would be nice to have some examples of best practices, on how applications should implement error handling and recovery.

Thanks for any tips!

[slawlor]

So it'll always be more performant to handle error explicitly, however it really depends on the supervision model you want to implement. The Erlang mentality is "let it crash" which can happily be applied here if you have a proper supervision model in place.

For example, consider if by failing an IO operation, the entire state of the actor is no longer valid. In that case it might be worth crashing the actor, and failing it so it'll be re-spawned by the supervisor with a fresh, clean state. On the other hand, in something like a webserver, not finding a file you want to handle as a 404 gracefully rather than a request 500 which might happen if the actor died.

Letting them be terminated + re-spawned is just fine, and expected. They're extremely lightweight (as light as tokio tasks), with only minor overhead in created structs. However if you have a lot of other actors with a handle to the actor which just died, they all need to have their handles refreshed. So that's something to keep in mind, entry-points are generally long-lived less-fallible actors which maybe handle requests with children that are more fallible (i.e. factory-style pattern).

[cdbennett]

Thanks for the explanation!