If you annotate a Kotlin function with @Throws, does it force other Kotlin code to catch the exception? Explain what changes and what does not.

## What `@Throws` is and is not `@Throws` is an **interop annotation**. It tells the Kotlin compiler to add the listed exception types to the **`throws` clause of the generated JVM method**. That is the entire effect. It is consumed by the **Java** compiler when Java code calls the function; the **Kotlin** compiler does not use it for any checking. ## What does NOT change - **Kotlin callers** are never forced to `try/catch` or to declare the exception. Kotlin has no checked exceptions, and `@Throws` does not add any. - **Runtime behavior** is unchanged: the same `Throwable` is thrown from the same line, whether or not the annotation is present. - **Kotlin compiler flow analysis** ignores it — there is no warning if a Kotlin caller does not handle the exception. ## What DOES change - The **JVM method signature** gains `throws X, Y` for the listed classes. You can verify this by decompiling the `.class` or viewing the Java-facing stub. - **Java callers** can now `catch` the listed checked exception without the *"exception never thrown"* error, and may be **required** to handle it if it is checked. ## Demonstration ```kotlin import java.io.IOException @Throws(IOException::class) fun load(): String = throw IOException("boom") fun kotlinCaller() { // No try/catch required — compiles fine. // The IOException still propagates at runtime exactly as before. val s = load() } ``` The Kotlin `kotlinCaller` needs no handling. A Java caller, however, must deal with the checked `IOException`: ```java // Java: must catch or declare String s; try { s = FileKt.load(); } catch (IOException e) { /* required */ } ``` ## Why Kotlin made this choice Kotlin's designers concluded that checked exceptions in large codebases often lead to **boilerplate `try/catch` blocks that swallow or rethrow** without adding value, so Kotlin dropped enforcement. `@Throws` exists only so Kotlin can still **participate cleanly** in Java's checked-exception world at the boundary. ## Practical takeaways - Use `@Throws` only on **Java-facing public APIs**; it is noise on internal Kotlin-only code. - Do not rely on it for safety inside Kotlin — document and handle exceptions explicitly instead. - Removing it can be a **binary-incompatible** change for Java callers that declared the checked exception (their code may stop compiling).