We’ll spend the next few lessons learning about Kotlin exceptions. Errors are a normal part of programming, and Kotlin provides nice ways for handling them. Let’s learn more!
It’s natural to make mistakes when you write computer programs. But even well-designed programs may encounter errors!
Imagine the following scenario.
You design an app that prompts the user to enter a number that you plan to use in a mathematical calculation.
What you receive is a String
, so you need to convert it to an Int
.
What could go wrong?
Let’s find out!
What is happening here?
Let’s examine the documentation for String.toInt
try-catch
try-catch
In Kotlin, when code that we write or call encounters an error, it can throw an Exception
.
Over the next few lessons we’ll explore Kotlin’s error-handling mechanisms and how to design and throw them in our own code.
But let’s start at looking at how to handle exceptions that we might encounter.
To do this we use a new Kotlin programming construct: try-catch
.
Let’s see how that works!
try-catch
consists of two or more code blocks.
First, the try
block, containing the code that might throw an exception.
Second, one or more catch
blocks that handle various kinds of exceptions that the code might throw.
Let’s look at some code that can generate several kinds of exceptions and see how to handle them:
Create a method named catcher
that takes, as a single parameter, a Faulter
that has a fault
method.
You should call that fault
method.
If it generates no exception, you should return 0.
If it generates a null pointer exception, you should return 1.
If it throws an illegal argument exception, you should return 2.
If it creates an illegal state exception, you should return 3.
If it generates an array index out of bounds exception, you should return 4.
One of the more difficult parts of exceptions is understanding how code flow changes when an exception is thrown.
When an exception is thrown, Kotlin jumps into the first enclosing catch
block.
This might be in that method, or in calling method, or even in the caller’s caller or higher up.
Let’s look at an admittedly contrived example:
Don’t worry if this doesn’t make perfect sense yet—we’ll get lots of practice with this over the next few days!
Write a method named retrieveValue
.
retrieveValue
takes an instance of Faulter
and returns the result of retrieving its value
property,
which has type Int
.
Seems simple!
Except there is just one small problem.
Faulter
was implemented by a friend that didn't take CS 124, and so it's getter is pretty buggy.
A lot of the time it will throw an exception rather than return the value.
But you did take CS 124, and so you know how to catch the exception and retry the call to getValue
.
Note that getValue
may fault multiple times before succeeding, and you should retry until it successfully
returns a value.
Need more practice? Head over to the practice page.