An exception is an abnormal computational condition that interrupts normal processing and can trigger failure handling. In actor systems, keep business logic on the happy path: let the actor fail and let supervision decide what happens next. section 5.1.2
A supervisor can respond to a failing actor in three ways:
- Restart the actor, preserving its ActorRef and mailbox while creating a new actor instance. section 5.1.2
- Resume the same actor instance and log the exception without stopping it. section 5.1.2
- Stop the actor so it no longer processes messages. section 5.1.2
Exceptions in a stream
A stream mapping -1 to 1 through 100 / elem emits -100, logs an ArithmeticException caused by division by zero, and stops. Adding recover can replace that failure with 0, but the stream still reports the failure and produces only the recovered value after the error. Logging risky operations makes the failure observable. section 16.3
Modeling failure as data
A Result(value, isValid, message) value can represent either successful division or an ArithmeticException without forcing the stream to fail. Downstream processing can then send invalid results to a separate sink. section 16.3.2
Figure 5.6 Supervisor wrapping an actor’s behavior and deciding on a recovery action after an exception
Use the supervisor diagram to trace how actor behavior is wrapped and how an exception selects a recovery action. section 5.1.2
