Take the block's default exit when a condition's arithmetic fails

[joaothallis]

Why

A condition expression on a Case block can perform arithmetic that faults at runtime even when every operand is a valid number, division by zero being the canonical case. Kernel.//2 raises ArithmeticError, which is neither an Expression.Error nor a RuntimeError, so it slipped past evaluate_expression_block/2's rescue and crashed the process evaluating the flow instead of simply failing the condition.

What

• evaluate_expression_block/2 now rescues ArithmeticError and returns {:error, :arithmetic, message}. Both condition paths, Case.evaluate_outgoing/5 and Exit.evaluate/2, already treat an {:error, _, _} result as an unusable condition and fall through to the block's default exit, so the run continues. This is exactly how a non-numeric operand (an Expression.Error) already behaves.
• Reordered Exit.evaluate/2's case clauses. Its {:error, reason, bad_parts} clause was already unreachable, shadowed by the preceding other when not is_boolean(other) guard; the typed error return now makes the dead clause visible to the compiler.

Tests

• evaluate_expression_block/2 returns {:error, :arithmetic, _} instead of raising.
• A Case block whose exit test divides by zero selects the default exit.

Scope

Targeted at ArithmeticError (division by zero is the observed high-volume case). Non-numeric operands are already handled via Expression.Error; both now fail the same way, by taking the block's default exit.

🤖 Generated with Claude Code

[joaothallis]

Superseded by turnhub/expression#372. The cleaner fix is in the expression library, which already reraises a RuntimeError raised during evaluation as Expression.Error; ArithmeticError was simply a missing case in that clause. With that, evaluate_expression_block/2's existing Expression.Error handling already routes a division-by-zero condition to the default exit, so no flow_runner change is needed.