# Kotlin and Exceptions

DevFeed: [Kotlin and Exceptions](<https://devfeed.tech/articles/kotlin-and-exceptions-26024.md>)

Original publisher: [Read original article](<https://elizarov.medium.com/kotlin-and-exceptions-8062f589d07?source=rss-4762e889f8fc------2>)

Author: Roman Elizarov

Published: 2020-06-10T08:18:06Z

Content type: article

Language: en

Sources: [Stories by Roman Elizarov on Medium](<https://devfeed.tech/sources/stories-by-roman-elizarov-on-medium.md>)

Topics: [Exception](<https://devfeed.tech/topics/exception.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Java](<https://devfeed.tech/topics/java.md>), [Error Handling](<https://devfeed.tech/topics/error-handling.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [api-design](<https://devfeed.tech/tags/api-design.md>), [code](<https://devfeed.tech/tags/code.md>), [error-handling](<https://devfeed.tech/tags/error-handling.md>), [exception-handling](<https://devfeed.tech/tags/exception-handling.md>), [exceptions](<https://devfeed.tech/tags/exceptions.md>), [java](<https://devfeed.tech/tags/java.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [programming](<https://devfeed.tech/tags/programming.md>)

## AI overview

The article examines Kotlin exceptions by tracing their origins to Java checked exceptions. It explains how checked exceptions were intended to reduce missed error checks, then discusses problems including boilerplate, overly broad API declarations, ignored exceptions, and poor compatibility with Java 8 lambdas and streams.

## Source excerpt

Photo by John Mark Arnold on Unsplash What are Kotlin Exceptions and how should you use them? To figure it out let's look at their origins first. Exceptions came to Kotlin from Java. The story with exceptions in Java is complicated, though. I'll give a brief overview. The Origin Java has a unique concept of checked exceptions that were designed to solve the problem of verbose and error-prone error-handling (pun intended). In languages predating Java, like in venerable C, you have to write code like shown in this snippet when doing basic input/output: file = fopen("file.txt", "r"); if (file == NULL) { // handle error & return } // work with file, check for error after each file operation Every time you perform an operation that might fail due to some external circumstance, which happens especially often with files and network, you have to write code that checks the corresponding error condition and handles it. That's tedious, easy to forget, hard to debug. Java set on a noble goal to eliminate this problem. The solution was to use checked exceptions. Every file I/O operation is declared as throws IOException in Java and the compiler checks that you either handle it or declare that you rethrow it. The beauty of this is that you can write exception-handling code once for a whole bunch of I/O operations and you cannot forget writing it since the Java compiler is there to help you. file = FileInputStream("file.txt"); // throws IOException No error-handling boilerplate, no more missed error checks. It was such a bliss to program in Java... for a while. Problems Problems with checked exceptions accumulated over the years. Memory input/output APIs like ByteArrayInputStream were still declared to throw IOException that you had to handle even though it never happened, people abused checked exceptions in API design leading to long, contagious lists of thrown exceptions, developers routinely caught and ignored checked exceptions just to fit some exception-throwing API under an in