docs(agents): Forbid introducing new catch Throwable (#5944)

* docs(agents): Forbid introducing new catch Throwable

Add an "Exception Handling" section to AGENTS.md telling agents to catch
the narrowest exception type the guarded code can throw, and to never add
a new catch (Throwable). The repo already has ~355 such catches in main
sources; they are legacy and should not be read as a precedent.

A broad catch swallows OutOfMemoryError, StackOverflowError, ThreadDeath
and LinkageError, and hides bugs in our own code behind a log line. The
"never crash the host app" requirement is what usually motivates these
catches, so the section points at ExceptionUtils.rethrowIfFatal as the
way to satisfy it, and calls out the two cases that need care: probing an
optional compileOnly dependency via a LinkageError subclass, and not
swallowing InterruptedException.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* docs(agents): Drop the two related cases from Exception Handling

The LinkageError and InterruptedException notes were detail the core rule
does not need.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Author: runningcode

AGENTS.md

@@ -154,6 +154,33 @@ The repository is organized into multiple modules:
 - **Formatting**: Enforced via Spotless - always run `./gradlew spotlessApply` before committing
 - **API Compatibility**: Binary compatibility is enforced - run `./gradlew apiDump` after API changes
 
+### Exception Handling
+
+**Never introduce a new `catch (Throwable)`.** Catch the narrowest type the guarded code can
+actually throw. The repository still contains many pre-existing broad catches; they are legacy,
+not a precedent to follow.
+
+A broad catch swallows `OutOfMemoryError`, `StackOverflowError`, `ThreadDeath` and `LinkageError` —
+conditions the JVM/ART cannot recover from and that leave the process in an undefined state — and
+it hides real bugs in our own code behind a log line.
+
+"The SDK must never crash the host application" is not a reason to catch `Throwable`. That goal is
+served by `io.sentry.util.ExceptionUtils.rethrowIfFatal`, which lets the non-recoverable throwables
+through while leaving everything else for the caller to log or ignore:
+
+```java
+try {
+  doSomethingRisky();
+} catch (Throwable t) {
+  ExceptionUtils.rethrowIfFatal(t);
+  options.getLogger().log(SentryLevel.ERROR, "Failed to do something risky", t);
+}
+```
+
+Apply that pattern only where a broad catch is genuinely unavoidable — an entry point that runs
+arbitrary user code or third-party callbacks. Everywhere else, name the exception types. Say in the
+PR description why the broad catch is necessary.
+
 ### Testing Requirements
 - Write comprehensive unit tests for new features
 - Android modules require both unit tests and instrumented tests where applicable