Chapters

Hide chapters

Kotlin Apprentice

Second Edition · Android 10 · Kotlin 1.3 · IDEA

Before You Begin

Section 0: 3 chapters
Show chapters Hide chapters

Section III: Building Your Own Types

Section 3: 8 chapters
Show chapters Hide chapters

Section IV: Intermediate Topics

Section 4: 9 chapters
Show chapters Hide chapters

20. Exceptions
Written by Irina Galata

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

People interact with software as developers and as users, and sometimes they make mistakes. A user could, for example, input invalid data, and a developer could forget to validate it. It’s important to notice and handle defects and potential weaknesses in your code in order to avoid unpredictable behavior of your app and unsatisfying experiences for its users.

Exceptions are a convenient way to detect errors in software. This concept is used in a wide variety of programming languages, including Kotlin.

What is an exception?

An exception is primarily an event which signals that something went wrong during program execution. Exceptions are represented by the Exception Java class, which is a superclass of all exceptions in Java and Kotlin programs — e.g., NullPointerException, IOException, etc. Depending on their nature, these events should be caught at runtime or fixed to prevent the exception from happening in the first place. I will discuss catching exceptions later in this chapter

Conversely, another type of critical event, an error — represented by Error and its subclasses — should not be handled but should instead be fixed, because it’s the result of serious problems in a program, like inappropriate memory usage, for example.

Both Exception and Error extend Throwable and, therefore, could be thrown by the JVM or manually from code using the keyword throw, in order to notify the user of the code that a problem occurred. Every Throwable object can contain a message and a cause — another Throwable instance that caused this error or exception, and a stacktrace.

Let’s see how a program behaves when an exception occurs and you don’t handle it. Imagine a main() function that calls someFunction(), which calls anotherFunction(), which in turn calls oneMoreFunction() that throws an exception with the message “Some exception”.

Your program can be represented as a long chain of function invocations. When something goes wrong somewhere in oneMoreFunction(), an exception gets thrown and the normal execution flow interrupts.

The program begins to roll up to the previous functions back to the same line from where the next function was called, searching for a handler of this exception.

Without handling the exception, the process ends up in the entry point of your app — the main() function — and then the app crashes, your user sees an annoying error message.

You will see the stacktrace of this exception in your terminal:

A stacktrace is a detailed description of an exception that occurred in your program. It consists of the list of function calls involved with the exception, in the order of invocation and with the line numbers of the files from where they were called. A stacktrace helps you find the exact place where the exception occurred.

To prevent the app from crashing, you should handle an exception; you can do that in any function in the chain that led to the exception. Now look how things change if you handle an exception:

While rolling up your program, it finds a handler inside someFunction() and, after handling an alternate execution, the program flow re-starts and your app doesn’t crash.

For the project that follows, you will use exceptions to troubleshoot launch issues, mechanical failures and encounters with aliens!

Throwing exceptions

Let’s imagine you’re a spacecraft engineer and your main responsibility is to launch a craft for investigation of deep space. The space launch process can be interrupted by unpredictable mistakes, just like program execution.

class SpaceCraft {

  private var isConnectionAvailable: Boolean = false
  private var isEngineInOrder: Boolean = false
  private var fuel: Int = 0
  var isInSpace: Boolean = false

  fun launch() {
    if (fuel < 5) {
      sendMessageToEarth("Out of fuel. Can't take off")
      return
    }

    if (!isEngineInOrder) {
      sendMessageToEarth("The engine is broken. Can't take off")
      return
    }

    if (!isConnectionAvailable) {
      sendMessageToEarth("No connection with Earth. Can't take off")
      return
    }

    sendMessageToEarth("Trying to launch...")
    fuel -= 5
    sendMessageToEarth("I'm in space!")
    sendMessageToEarth("I've found some extraterrestrials")
    isInSpace = true
  }

  fun sendMessageToEarth(message: String) {
    println("Spacecraft to Earth: $message")
  }
}
object SpacePort {
  fun investigateSpace(spaceCraft: SpaceCraft) {
    spaceCraft.launch()
  }
}
fun main(args: Array<String>) {
  val spaceCraft = SpaceCraft()
  SpacePort.investigateSpace(spaceCraft)
}
Spacecraft to Earth: Out of fuel. Can't take off.
fun launch() {
  if (fuel < 5) {
    throw Exception("Out of fuel. Can't take off.")
  }

  if (!isEngineInOrder) {
    throw Exception("The engine is broken. Can't take off.")
  }

  if (!isConnectionAvailable) {
    throw Exception("No connection with Earth. Can't take off.")
  }
...
}

Handling exceptions

As you throw exceptions, as long as you can recover from them, you should handle them. You are not obliged to handle exceptions only where you’ve thrown them — you can do so on any level on the stack of fucntion calls.

fun investigateSpace(spaceCraft: SpaceCraft) {
  try {
    spaceCraft.launch()
  } catch (exception: Exception) {
    spaceCraft.sendMessageToEarth(exception.localizedMessage)
  }
}

Creating custom exceptions

You already know that every child of Exception is an exception, too. Therefore, you just need to create subclasses of Exception:

class OutOfFuelException :
        Exception("Out of fuel. Can't take off.")
class BrokenEngineException :
        Exception("The engine is broken. Can't take off.")
class SpaceToEarthConnectionFailedException :
        Exception("No connection with Earth. Can't take off.")
fun launch() {
  if (fuel < 5) {
    throw OutOfFuelException()
  }

  if (!isEngineInOrder) {
    throw BrokenEngineException()
  }

  if (!isConnectionAvailable) {
    throw SpaceToEarthConnectionFailedException()
  }
...
}
fun investigateSpace(spaceCraft: SpaceCraft) {
  try {
    spaceCraft.launch()
  } catch (exception: OutOfFuelException) {
    spaceCraft.sendMessageToEarth(exception.localizedMessage)
  } catch (exception: BrokenEngineException) {
    spaceCraft.sendMessageToEarth(exception.localizedMessage)
  } catch (exception: SpaceToEarthConnectionFailedException) {
    spaceCraft.sendMessageToEarth(exception.localizedMessage)
  }
}
fun refuel() {
  fuel += 5
  sendMessageToEarth("The fuel tank is filled.")
}

fun repairEngine() {
  isEngineInOrder = true
  sendMessageToEarth("The engine is in order.")
}

fun fixConnection() {
  isConnectionAvailable = true
  sendMessageToEarth("Hello Earth! Can you hear me?")
  sendMessageToEarth("Connection is established.")
}

fun land() {
  sendMessageToEarth("Landing...")
  isInSpace = false
}
fun investigateSpace(spaceCraft: SpaceCraft) {
  try {
    spaceCraft.launch()
  } catch (exception: OutOfFuelException) {
    spaceCraft.sendMessageToEarth(exception.localizedMessage)
    spaceCraft.refuel()
  } catch (exception: BrokenEngineException) {
    spaceCraft.sendMessageToEarth(exception.localizedMessage)
    spaceCraft.repairEngine()
  } catch (exception: SpaceToEarthConnectionFailedException) {
    spaceCraft.sendMessageToEarth(exception.localizedMessage)
    spaceCraft.fixConnection()
  } finally {
    if (spaceCraft.isInSpace) {
      spaceCraft.land()
    } else {
      investigateSpace(spaceCraft)
    }
  }
}

Difference between Java and Kotlin exceptions

Checked exceptions

If you’re familiar with Java, you may remember that there are two types of exceptions — checked and unchecked. Checked exceptions must be either handled or declared after your method signature with the throws keyword. Unchecked exceptions can be ignored, but then crash your app when not handled. Conversely, all exceptions in Kotlin are unchecked and, therefore, you’re not forced to handle them or declare them. Your program still terminates when exceptions get thrown.

try as an expression

In Kotlin, the try-catch construction is an expression. This means that you can get a value from a try-catch block and can equate it to some variable:

val date: Date = try {
    Date(userInput) // try to parse user input
  } catch (exception: IllegalArgumentException) {
    Date() // otherwise use current date
  }
}

Challenges

Key points

  • Exceptions are the events that happen when something goes wrong in your program.
  • Extend the Exception class or its subclasses to create custom exceptions.
  • Throw an exception using the throw keyword.
  • Do not catch the base class Exception, use the most specific exception class you can.
  • Create custom exceptions for uncommon cases to differentiate them.
  • When handling exceptions, place the code that should be executed whether an exception occurs or not in the finally block.
  • All exceptions in Kotlin are unchecked.
  • Don’t ignore exceptions.
  • Try-catch is an expression.

Where to go from here?

Exception throwing and handling can be a bit of an art. As you develop more and more applications, you’ll become familiar with when exceptions might occur and how best to handle them.

Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2024 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now