Today we'll continue exploring Kotlin exceptions.
First, we'll look at how we can
throw our own exceptions.
Next, we'll discuss the different types of Kotlin exceptions and how they are used.
Aren't errors fun?
Let's do this.
Last time we looked at
try-catch, Kotlin's syntax for handling exceptions.
But where do exceptions come from?
Some exceptions are generated directly by Kotlin.
For example, executing this code will generate a
However, Kotlin also provides a way for us to
throw exceptions directly—the
Let's see how that works.
Kotlin has several built-in exceptions that you may find useful in your own code.
throw is particularly useful when there is no valid way to continue.
Maybe your method has received bad input, or encounters a situation that it is unprepared to handle.
We'll discuss this more in future lessons.
We've already seen one convenient way to throw exceptions in Kotlin:
require throws an
IllegalArgumentException, but provides syntax that is
somewhat more convenient that
Let's look at an example:
In Kotlin the
Throwable class is the superclass of all objects that can be thrown, either using
throw or in case of an error like a null pointer exception.
Throwable has two subclasses that are handled differently.
We've been discussing exceptions so far.
The second category is errors. These are serious problems that you should not try to handle. According to the documentation:
An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions.
However, it is worth noting that
assert generates an error.
It is also possible to generate errors through programming errors, like this one:
This generates a
You may get much more familiar with this kind of error soon...
For those of you familiar with Java, you may remember that the Java compiler forces you to handle certain types of exceptions, known as checked exceptions.
Kotlin differs from Java in this regard. Kotlin does not have checked exceptions. It does not force you to handle any exceptions. There are reasons for this design choice, which you can start reading more about here if you are interested.