Kotest's shouldThrow<T> block returns a value. What is that value, how do you assert on it, and when do you need the shouldThrowUnit variant instead?

## The shape of the assertion In Kotest's assertions library (`io.kotest.assertions.throwables`), the exception assertions are *expressions*, not statements. `shouldThrow<T> { block }` runs the block, and: - if nothing is thrown, it fails with "Expected exception ... but no exception was thrown"; - if something of type `T` (or a subtype) is thrown, it **returns that throwable, typed as `T`**; - if something else is thrown, it fails and reports what was thrown instead. That return value is the whole point of this design. Many frameworks make you pass the assertion into a callback or re-catch the exception yourself; Kotest lets you write the arrange/act inside the lambda and keep the assertions outside it, where they read like every other assertion in the test. ## Using the returned exception ```kotlin val ex = shouldThrow<AccountLockedException> { accounts.login("ada", "wrong") } ex.message shouldContain "locked" ex.remainingAttempts shouldBe 0 ``` Because `T` is reified and the return type is `T`, `remainingAttempts` — a property that exists only on your exception class — is reachable with no cast and no smart-cast dance. This is why over-broad expectations hurt: `shouldThrow<Exception>` compiles but gives you back only `Exception`, so you lose the typed accessors and you also weaken the assertion (any exception subtype passes). Kotest ships throwable matchers in `io.kotest.matchers.throwable` that pair with the returned value: - `shouldHaveMessage("...")` — asserts the full message; - `shouldHaveCause { it.shouldBeInstanceOf<IOException>() }` — asserts a cause exists and lets you assert on it; - `shouldHaveCauseInstanceOf<T>()` (subtype allowed) and `shouldHaveCauseOfType<T>()` (exact type); - `shouldNotHaveCause()`. For partial message checks, prefer a string matcher on `ex.message` (`shouldContain`, `shouldMatch` with a regex) over exact equality: messages built from interpolated values, locales, or third-party libraries change more often than the behaviour you actually care about. ## The Unit variants The primary overload is declared over a block returning `Any?`. When the block's last expression is a `Unit`-returning call, Kotlin's inference can pick an unexpected overload or complain, especially when the block is a single statement. Kotest therefore ships parallel functions whose block type is `() -> Unit`: - `shouldThrowUnit<T> { ... }` - `shouldThrowExactlyUnit<T> { ... }` - `shouldThrowAnyUnit { ... }` Semantics are identical; only the block's declared return type differs. A practical rule: write `shouldThrow` first, and only reach for the `Unit` variant if the compiler objects. A common workaround people use instead — adding a trailing dummy expression to the block — works but is noise. ## The negative forms The family also has `shouldNotThrowAny { ... }`, `shouldNotThrow<T> { ... }` and `shouldNotThrowExactly<T> { ... }`. `shouldNotThrowAny` returns the block's own value, which makes it useful as a wrapper around a call whose result you then assert on — it converts an unexpected exception into a readable assertion failure instead of a raw stack trace, which matters mostly for diagnostics rather than for pass/fail. ## Common mistakes 1. **Discarding the return value** and then re-running the call outside the block to inspect the exception — the call runs twice, and side effects run twice with it. 2. **Catching manually** (`try { ... ; fail("expected") } catch (e: X) { ... }`) — verbose, and it is easy to forget the `fail` so the test passes when nothing throws. 3. **Putting assertions inside the block** after the throwing call. They never execute, so the test silently asserts nothing beyond "something was thrown". 4. **Asserting on `toString()`** of the exception rather than `message`; `toString()` includes the class name and is brittle. 5. **Using `shouldThrowAny` and then casting.** If you know the type, name it and let the return type do the work. ## Why interviewers ask It separates people who have only copied a `shouldThrow { }` line from people who use it as a value-producing assertion. The follow-up is usually about asserting on causes in wrapped exceptions — a real-world case where the returned exception plus `shouldHaveCauseInstanceOf` is the shortest correct answer.