Mockito's Answers.RETURNS_SMART_NULLS changes what an unstubbed mock method hands back. What does it return, what is a SmartNullPointerException, and when would you turn it on?

## The problem it solves With Mockito's normal default answer, any unstubbed method returning an object gives back `null`. Nothing complains at that moment. The class under test then does something with the value — `user.getName()`, `result.total()` — and blows up with a bare `NullPointerException` several frames away. The stack trace shows production code; the actual defect is a stubbing you forgot to write, and nothing in the failure tells you which one. `RETURNS_SMART_NULLS` closes that gap. ## What a smart null is When the default answer is `Answers.RETURNS_SMART_NULLS` (implemented by `ReturnsSmartNulls`), an unstubbed call whose return type is mockable produces a small proxy of that type instead of `null`. The proxy has one job: any method invoked on it throws `SmartNullPointerException`, a subclass of Mockito's reporting errors. The message reads roughly *"You have a NullPointerException here: ... because this method call was not stubbed: repo.findById(42)"* and includes the location where the unstubbed call happened. Its `toString()` is also overridden to say it is a SmartNull from that call, so a value that ends up in an assertion message or a log identifies itself. For return types that cannot be proxied — primitives, and object types the active mock maker cannot handle — it falls back to `ReturnsMoreEmptyValues`, a slightly more generous version of the standard empty values: `0`/`false` as usual, but `""` for `String` and a zero-length array for array types instead of `null`. ## How to enable it Per mock, three ways: - `@Mock(answer = Answers.RETURNS_SMART_NULLS) OrderRepository repo;` - `mock(OrderRepository.class, Answers.RETURNS_SMART_NULLS)` - `mock(OrderRepository.class, withSettings().defaultAnswer(Answers.RETURNS_SMART_NULLS))` There is also a global route (a `MockitoConfiguration` class implementing `IMockitoConfiguration` with `getDefaultAnswer()` returning smart nulls), which the Mockito authors themselves once suggested might become the default. It never did, and turning it on build-wide has real costs: every unstubbed call now allocates a proxy, and tests that legitimately expect `null` from a collaborator start behaving differently. ## What it does not do It is not a strictness mechanism. It only fires when something *calls a method* on the returned value. Code that stores the value, passes it along, compares it with `==`, or null-checks it will never trigger the exception — the smart null is simply a non-null object, which incidentally means `if (x == null)` branches take the *other* path than they would with plain defaults. That behaviour difference is exactly why smart nulls are best used as a temporary diagnostic on the mock you are investigating rather than as a permanent global setting. It also does not detect *unnecessary* stubbings or argument mismatches — that is `Strictness.STRICT_STUBS`, and the two are complementary: strict stubs catches "you stubbed something that was never called" and "you called with different arguments"; smart nulls catch "you never stubbed something the code needed". ## Practical workflow A productive debugging loop when a mock-heavy test dies on an NPE: 1. switch the suspect mock to `RETURNS_SMART_NULLS`; 2. re-run — the failure now names the unstubbed call; 3. add the stubbing; 4. revert the mock to the default answer so the test does not depend on the diagnostic mode. Some teams keep it on permanently for repository-style collaborators whose methods never legitimately return `null`, and that is defensible; keeping it on for collaborators that *do* return `null` meaningfully (a cache lookup, a `Map.get`) is not, because the test then diverges from production behaviour in a way nobody notices.