Java to Kotlin

Chapter 19. Throwing to Returning

Java uses checked and unchecked exceptions to represent and handle errors. Kotlin supports exceptions, but doesn’t build checked exceptions into the language in the same way. Why did Kotlin reject Java’s approach, and what should we use instead?

You don’t have program computers for long to discover that things go wrong…

…in so many ways.

Early in their careers, your authors tended to gloss over errors. We often still do, at least early in a project. As the system grows, though, we learn how failures affect the application and start to add code to cope—at first piecemeal, later with some strategy informed by experience. In this respect our error handling evolves in the same way as other aspects of our software design. Sometimes we design up front, making use of our experience of similar systems; other times we allow the writing of the software to teach us what it needs.

In the absence of a more deliberate strategy, most systems default to raising exceptions when something goes wrong, and catching and logging those exceptions at some outer level. Command-line utilities will just exit in this case, hopefully having provided enough information for the user to correct the problem and try again. A server app, or a GUI with an event loop, will usually abort only the current interaction and get on with the next.

Often this is just a poor experience for our users, but sometimes the error will corrupt the persistent state of the system, so correcting ...