Kotlin is a modern programming language that compiles to Java bytecode. It's free and open source, and makes coding for Android even more fun.
In the previous article, you learned more about object-oriented programming by digging into abstract classes, interfaces, inheritance, and type aliases in Kotlin.
In this post, you'll continue to learn about programming in Kotlin by learning about exceptions and how to handle them.
1. Exception Handling
Exceptions are used to indicate a problem in our code during a program's execution. Exception handling is the capability to address (or handle) the exception that might occur. If we don't handle any exception that occurs, our program will stop execution abruptly—crashing our app immediately.
Exception handling allows our program to continue execution even if there was an exception (though it is highly recommended to log your exceptions and report them using a crash reporting tool like Crashlytics).
In Java, we have two kinds of exceptions: checked and unchecked. I'll briefly explain both of them, but we'll start with unchecked exceptions.
Unchecked Exceptions
These are exceptions that are thrown because of flaws in your code. They are a direct or indirect subclass of the RuntimeException
superclass.
Examples of unchecked exceptions include:
ArithmeticException
: thrown when you divide by zero.ArrayIndexOutOfBoundExceptions
: thrown when an array has been accessed with an illegal index.SecurityException
: thrown by the security manager to indicate a security violation.NullPointerException
: thrown when invoking a method or property on a null object.
A method that might throw an unchecked exception doesn't contain any information about the exception thrown on its method declaration.
public Integer divideByZero(Integer numerator, Integer denominator) { return numerator / denominator; } divideByZero(7, 0) // throws ArithmeticException
These types of exception can be prevented by coding right. In the code above, we should have checked if the denominator was zero before performing the operation. For these exceptions, the developer doesn't need to catch the exception using the try...catch
block. In other words, we aren't forced by the compiler to wrap the code that might trigger the exception in a try...catch
block. Instead, we should just make sure the exceptions never occur in the first place.
Also, remember, Kotlin is a null safe language. In other words, it can help us avoid getting NullPointerExceptions
in our code. You can read the Nullability, Loops, and Conditions post to get a refresher on null safety in Kotlin.
Checked Exceptions in Java
A method that might throw a checked exception needs to declare so in its method signature using the throws
keyword. If you call a method that throws a checked exception, you either need to throw it again from your function or to catch it and handle it using a try...catch
block.
Checked exceptions are exceptions that are checked at compile time. These kinds of exceptions inherit from the Exception
class. An example of this kind of exception is IOException
. This can occur when you try to access a file that can't be opened because it doesn't exist. (FileNotFoundException
is a subclass of IOException
.)
// perform in a background thread public void editFile(File file, String text) { try { file.getParentFile().mkdirs(); FileOutputStream fileOutputStream = new FileOutputStream(file); Writer writer = new BufferedWriter(new OutputStreamWriter(fileOutputStream)); try { writer.write(text); writer.flush(); fileOutputStream.getFD().sync(); } finally { writer.close(); } } catch (IOException e) { // Log the exception e.printStackTrace(); } }
In the preceding code, we used a try...catch
block to handle the IOException
inside the editFile()
method. We can now call the editFile()
method as normal, and the compiler won't complain.
editFile(new File(""), "my text");
Looking at the code below, we've refactored the method to instead use the throws
keyword in the method signature. This indicates to callers that they need to handle the exception IOException
that might be thrown when calling the method editFile()
.
// this should be in a background thread public void editFile(File file, String text) throws IOException { file.getParentFile().mkdirs(); FileOutputStream fileOutputStream = new FileOutputStream(file); Writer writer = new BufferedWriter(new OutputStreamWriter(fileOutputStream)); try { writer.write(text); writer.flush(); fileOutputStream.getFD().sync(); } finally { writer.close(); } }
To call the method above, we need to surround it in a try...catch
block to handle the exception.
try { editFile(new File(""), "my text"); } catch (IOException e) { e.printStackTrace(); }
This has been a brief look at exceptions in Java. Let's now see how Kotlin handles exceptions.
2. Exceptions in Kotlin
The main difference between Kotlin and Java exception mechanisms is that all exceptions are unchecked in Kotlin. In other words, they are not explicitly declared in the function signatures, as they are in Java.
fun editFile(file: File, text: String) { file.parentFile.mkdirs() val fileOutputStream = FileOutputStream(file) val writer = BufferedWriter(OutputStreamWriter(fileOutputStream)) try { writer.write(text) writer.flush() fileOutputStream.fd.sync() } finally { writer.close() } }
Here, we have converted the editFile()
method to a Kotlin function. You can see that the function doesn't have the throws IOException
statement in its function signature. throws
isn't even a keyword in Kotlin.
Also, we can call this function without surrounding it with the try...catch
block—and the compiler won't complain. In other words, there's no such thing as checked exceptions in Kotlin. All exceptions are unchecked. (Note that if there is an exception thrown, program execution will stop as normal.)
If we think this exception might arise, we should still handle it by surrounding the method with a try...catch
block—but this is not enforced by the Kotlin compiler.
try { editFile(File(""), "text 123") } catch (e: IOException) { e.printStackTrace() }
If the exception thrown inside the editFile()
function is an instance of the IOException
class, our catch
block will be executed, and we simply print the stack trace for debugging purposes.
The try...catch
Block
The try
construct with catch
and finally
clauses in Kotlin is similar to that of Java.
fun foo() { try { throw Exception("Exception message") } catch (e: Exception) { println("Exception handled") } finally { println("inside finally block") } }
Here, we are throwing an Exception
object inside the try
block. Notice we didn't include the new
keyword as we do in Java to create a new instance. Also notice that we didn't specify the exception that will be thrown in the function signature as we would have to in Java.
We handle all subclasses and classes of type Exception
in the catch block. The optional finally
block is always executed—this is where we typically close any resources or connections that were previously opened so as to prevent resource leaks. For example, if you open a file or create a database or network connection in a try
block, you should close or free it in a finally
block.
Note that in Kotlin the throw
construct is an expression and can combine with other expressions.
val letter = 'c' val result = if (letter in 'a'..'z') letter else throw IllegalArgumentException("A letter must be between a to z")
Also, the try
construct can be used as an expression.
fun foo(number: Int) { val result = try { if (number != 1) { throw IllegalArgumentException() } true } catch (e: IllegalArgumentException) { false } println(result) } foo(2) // false
Here, we assigned the value returned from the try...catch
block to the result
variable. If the number is not 1
, it throws an IllegalArgumentException
and the catch
block is executed. The false
expression in the catch
block value will be assigned to the result
variable. If the number is 1
instead, then the true
expression value will be assigned to the result
variable.
Java Interop
Exceptions in Kotlin behave as normal in Java—but I want to make you aware of a useful annotation called @Throws
in Kotlin that might come in handy. Because all exceptions in Kotlin are unchecked, developers who consume your Kotlin code from Java might not be aware that your functions throw exceptions. However, you can still add the possible exceptions that might be thrown to a method signature with the @Throw
annotation. This will alert Java callers that they need to handle the exception.
Let's see a practical example of this annotation.
/* Functions.kt file */ fun addNumberToTwo(a: Any): Int { if (a !is Int) { throw IllegalArgumentException("Number must be an integer") } return 2 + a }
Here, we defined a Kotlin function that can throw an exception IllegalArgumentException
only if the type passed to the function is not of type Int
.
We call this top-level function addNumberToTwo()
directly from Java in the following way:
public void myJavaMethod() { Integer result = FunctionsKt.addNumberToTwo(5); System.out.println(result); // 7 }
This works fine; the compiler isn't complaining. However, if we want to communicate with Java callers that the addNumberToTwo()
top-level function throws an exception, we simply add the @Throws
annotation to the function signature.
@Throws(IllegalArgumentException::class) fun addNumberToTwo(a: Any): Int { if(a !is Int) { throw IllegalArgumentException("Number must be an integer") } return 2 + a }
This @Throws
annotation can accept a comma-separated list of arguments of exception classes. In the code above, we just included one exception class—IllegalArgumentException
.
Now we have to update our Java code to handle the exception.
public void myJavaMethod() throws IllegalArgumentException { Integer result = FunctionsKt.addNumberToTwo(5); System.out.println(result); }
If we decompile the Kotlin addNumberToTwo()
function, using the Show Kotlin Bytecode feature (if you're in IntelliJ IDEA or Android Studio, use Tools > Kotlin > Show Kotlin Bytecode), we'll see the following Java code:
// ... public static final int addNumberToTwo(@NotNull Object a) throws IllegalArgumentException { Intrinsics.checkParameterIsNotNull(a, "a"); if (!(a instanceof Integer)) { throw (Throwable)(new IllegalArgumentException("Number must be an integer")); } else { return 2 + ((Number)a).intValue(); } } // ...
In the generated Java code above (some elements of the generated code were removed for brevity's sake), you can see that the compiler added the throws
keyword to the method signature—because we included the @Throws
annotation.
Conclusion
In this tutorial, you learned more about programming in Kotlin by looking into exceptions. We saw that Kotlin doesn't have checked exceptions but that instead, all exceptions are unchecked. We also looked at how to handle exceptions using the try...catch
block and saw the usefulness of the @Throws
annotation in Kotlin for Java callers.
To learn more about the Kotlin language, I recommend visiting the Kotlin documentation. Or check out some of our other Android app development posts here on Envato Tuts!
-
Android SDKJava vs. Kotlin: Should You Be Using Kotlin for Android Development?
-
Android SDKIntroduction to Android Architecture Components
-
Android SDKGet Started With RxJava 2 for Android
-
Android SDKConcurrency in RxJava 2
by Chike Mgbemena via Envato Tuts+ Code
No comments:
Post a Comment