Preserve interruptible callback control flow

Author: flemming-n-larsen

docs/capabilities/CAP-001-event-dispatch-parity/design.md

@@ -36,7 +36,7 @@ Since Bot API 1.0.2, new-turn events dispatch at the end of `execute()`, which i
 
 ## Handler exceptions
 
-The Bot API's event publisher catches subscriber exceptions so one callback cannot prevent other subscribers from receiving the event. That is compatible with classic's continued battle processing, but it hides the failure from the process logs that form conformance evidence. `BotPeer` therefore reports throwables at the legacy callback boundary and then returns to the Bot API queue; `IDR-006` records this narrow exception-reporting rule.
+The Bot API's event publisher catches subscriber runtime exceptions so one callback cannot prevent other subscribers from receiving the event. That is compatible with classic's continued battle processing, but it hides the failure from the process logs that form conformance evidence. `BotPeer` therefore reports runtime exceptions at the legacy callback boundary and then returns to the Bot API queue; control-flow errors used by the Bot API for interruptible handlers pass through unchanged. `IDR-006` records this narrow exception-reporting rule.
 
 ## The guard
 

docs/decisions/IDR-006-report-legacy-handler-exceptions-at-the-bridge-boundary.md

@@ -12,15 +12,15 @@ title: Report legacy handler exceptions at the bridge callback boundary
 
 ## Decision
 
-`BotPeer` invokes every legacy robot event callback inside a bridge-owned boundary. If the callback throws, the boundary prints the throwable to the bot process's standard error and returns so the surrounding event queue can continue dispatching.
+`BotPeer` invokes every legacy robot event callback inside a bridge-owned boundary. If the callback throws a runtime exception, the boundary prints it to the bot process's standard error and returns so the surrounding event queue can continue dispatching. Errors used by the Bot API for control flow, such as interrupting an event handler, are not caught.
 
 ## Context
 
 The matched Tank Royale Bot API catches subscriber exceptions during event publication and otherwise provides no observable error to the conformance harness. Classic Robocode reports a `NullPointerException` thrown from `onStatus` while continuing the battle, so delegating event ordering to the Bot API is not enough to preserve the classic observable contract.
 
 ## Why this way
 
-The boundary is the narrowest place that sees the legacy callback before the Bot API swallows its exception. Reporting there preserves the Bot API's priority and queue implementation, keeps the robot lifecycle unchanged, and gives the harness the same error signature that classic exposes. Replacing the upstream dispatcher or stopping the bot would alter unrelated event and lifecycle behavior.
+The boundary is the narrowest place that sees the legacy callback before the Bot API swallows its runtime exception. Reporting there preserves the Bot API's priority and queue implementation, keeps the robot lifecycle unchanged, and gives the harness the same error signature that classic exposes. Leaving control-flow errors untouched preserves interruptible-handler semantics. Replacing the upstream dispatcher or stopping the bot would alter unrelated event and lifecycle behavior.
 
 ## Consequences
 

robocode-api/src/main/java/dev/robocode/tankroyale/bridge/BotPeer.java

@@ -454,8 +454,8 @@ private void dispatchCustomEvent(BotEvent botEvent) {
     private void dispatchRobotCallback(Runnable callback) {
         try {
             callback.run();
-        } catch (Throwable throwable) {
-            throwable.printStackTrace();
+        } catch (RuntimeException exception) {
+            exception.printStackTrace();
         }
     }