DEV Community: Leah

The Four Dots of Mystery

Leah — Tue, 17 Jun 2025 10:18:08 +0000

Every so often, you might come across the strange sight of :: in your Kotlin code.

This cheeky little four-eyed fella is the Callable Reference Operator. Implementing it creates a callable reference from a function, property or class.

What is a callable reference?

A callable reference is a separate object that represents a function, property or class. It does not execute immediately, rather it holds the reference until the moment that it is invoked.

For example:


fun add(a: Int, b: Int): Int {
    return a + b
}

val calculateNow = add(3, 5)
// 👆🏻 this variable makes a direct call to the 'add' function. 
// It will execute immediately

val calculateLater = ::add
// 👆🏻 this variable makes a callable reference of the 'add' function.
// It will only execute when the variable is invoked (as below 👇🏻)

calculateLater(2, 5)

The Kotlin.reflect API

The reference we create by using the Callable Reference Operator is always an object from the kotlin.reflect API (eg. an instance of KFunction, KProperty, or KClass). We can see this when we hover over our callable reference in the IDE:

KFunction2 tells us we are representing a function that has two parameters.
<Int, Int, Int> tells us the parameters are of type Int, as is the return type.

When might we use the Callable Reference Operator?

A callable reference is 'first-class' which means that it can be passed as an argument, stored in a variable, or returned from a function - just as any other data type - a Boolean, String, Int, etc.. This makes it particularly useful for passing into higher order functions.

The Callable Reference Operator in action

In the below examples, I demonstrate how the Callable Reference Operator can be used as a concise alternative to passing lambdas to functions in a few different case scenarios.

A function reference (::functionName)


fun isOdd(x: Int) = x % 2 != 0
val numbers = listOf(1, 2, 3)

numbers.filter(::isOdd) // [1,3]

// the above line does the same as 👇🏻

numbers.filter { isOdd(it) } // [1,3]

A property reference (ClassName::propertyName)


val strings = listOf("a", "bc", "def")

strings.map(String::length) // [1, 2, 3]

// the above line does the same as 👇🏻

strings.map { it.length } // [1, 2, 3]

Constructor reference (::ClassName)


data class Person(val name: String, val age: Int)

val personGenerator: (String, Int) -> Person = ::Person 

// the above line does the same as 👇🏻 

val personGeneratorUsingLambda: (String, Int) -> Person = { nameParam, ageParam -> 
        Person(nameParam, ageParam) 
    }

// we can also treat ::Person as a first class value in the following higher-order function 

fun createPeopleFromData(data: List<Pair<String, Int>>, personGenerator: (String, Int) -> Person): List<Person> {
  return data.map { (name, age) -> personGenerator(name, age)}
}

val listOfPeople = listOf(
    "Sidney" to 2,
    "Alf" to 5,
    "Morag" to 10
)

val people = createPeopleFromData(listOfPeople, ::Person)

// the above line does the same as 👇🏻 

val peopleUsingLambda = createPeopleFromData(listOfPeopleData) { nameParam, ageParam ->
    Person(nameParam, ageParam)
}

In this last example, you can really see how the code becomes more concise when we use the Callable Reference Operator.

Conclusion

Using the Callable Reference Operator is pretty neat. However, a clever, concise way of programming is only useful if it's also easy to understand for any other engineer who might come across it.

I don't come across the Callable Reference Operator very much in production code which implies one of two things: either there is a lack of knowledge / confidence in using it or that the knowledge is there but that engineers find it less intuitive or think it makes code less readable.

Personally, I don't currently read the Callable Reference Operator as fluently as I might read a lambda. But this will no doubt start to even out as I gain experience around using (and reading) this operator. I will certainly be looking out for it more in code and also look forward to utilising it more in my own work.

Kotlin Exception Handling: The Basics

Leah — Mon, 07 Apr 2025 20:45:14 +0000

In this post, I'll be taking a look at code Exceptions in Kotlin - what they are, where they come from and how we can handle them.

Throwable Superclass
Errors
Exceptions
Catching Exceptions
Throwing Exceptions
Centralised Error Handling
Custom Exceptions
Stack Trace
Things to Consider

First off, let's get some context and look at where the Exception class comes from:

👑 Throwable Superclass

Exceptions are a subclass of the superclass Throwable.

For languages such as Kotlin that run on the JVM, the class Throwable represents anything that is unusual or exceptional in your application.

Exceptions and Errors are the only direct subclasses of Throwable - however, many more subclasses stem from these two, and developers also have the opportunity to create their own, custom subclasses, too.

Errors V Exceptions - what's the difference?

In a nutshell: 
Errors occur when something goes wrong with the Java Virtual Machine (JVM). They are not usually recoverable.  
Exceptions occur when something unexpected happens in your application during runtime. Exceptions can be recovered from.

Padding the nutshell out a bit:

Errors

Errors prevent an application from completing its task, resulting in it terminating or needing to be restarted.

An Error can be caused by external factors such as system failures or resource depletion.

There are many error types, a few of the the common ones are:

Error Type	Example Errors
Class Loading Errors	`ClassNotFoundException`, `NoClassDefFoundException`
Linking Errors	`NoSuchMethodError`, `IncompatibleClassError`
Runtime Errors	`NullPointerException`, `ClassCastExcpetion`
System Level Errors	`OutOfMemoryError`, `StackOverflowError`
Compilation Errors	Syntax Issues, Type Mismatches

Exceptions

Exceptions occur when something unexpected - but not entirely beyond imagination - has happened within the code.

Exceptions interrupt the expected flow of a program, but (unlike Errors) they can be caught and dealt with (‘handled’).

In handling exceptions, we have the opportunity to recover from them and keep our application running. It's up to the Developer to decide how we handle these Exceptions - a few common coding scenarios and possible handling ideas are listed below:

Exception	Handled by:
File not found	Create default file
Invalid input	Request another input from user
Network failure	Retry connection

Note that an uncaught exception will become a runtime Error - so we must make sure to catch them!

Runtime Exceptions deserve an honourable mention. They describe exceptions that occur within the JVM (during runtime). Runtime exceptions are extremely common, so much so that the compiler allows them to go uncaught and unspecified.

Some common types Runtime Exceptions that you might have already encountered:

NullPointerException - when you try to perform operations on a null value
IllegalArgumentException - when an illegal argument has been passed
IllegalStateException - if an object has state that’s invalid

Catching Exceptions

In Kotlin, we can catch Exceptions by wrapping code in try-catch blocks. The exceptions we're looking to catch are not mistakes made by the engineer but plausible but plausible scenarios that shouldn’t happen, but could.

Some example scenarios where we might want to catch an exception:

A user enters an invalid username/password combination
A file that we are searching for is not found
User attempts to retrieve data that should exist in a database but doesn't
A user inputs zero as a divisor

To take this last example and put it into some code:


fun divider(a: Int, b: Int): Int {
    return try {
        a / b
    } catch (e: Exception) {   
        e.printStackTrace() // print the full stack trace of the exception
        0            // return a safe, default value
    }
}

Throwing Exceptions

We don’t always have to catch an exception at the point of its creation - in fact, it is often better to let the exception bubble up through the call stack. We do this by throwing our exception.

Throwing an Exception initialises an object with dynamic storage duration called the Exception Object. It might help to think of this Exception Object as a hot potato. The first person to pull it from the oven isn't wearing gloves and the potato gets tossed along a line of people until it reaches someone who is wearing gloves.

 A few reasons why throwing an Exception (rather than just catching in situ) is a good idea:

DRY PRINCIPLES Avoids multiple try catch blocks everywhere, resulting in cleaner code that is easier to read and test
CONTEXT There may be multiple scenarios in which the code triggering the exception is called. Each of these might benefit from a different, custom, response.
RETRIES If you catch an exception too early, you loose the opportunity to retry the call from an API level

Here's our divider function example again, this time, however, the Exception is thrown and caught further up the call stack.

fun main() {
 try {divider(2, 0)}
    catch (e: Exception) {
      e.printStackTrace() 
      0 
    }
}

fun divider(a: Int, b: Int): Int {
    if (b == 0 || a == 0) {
        throw Exception()
    }
    return a/b
}

Centralised Error Handling

In larger applications, all Exceptions can be managed in a single location, ensuring consistent handling and improved maintainability. This often happens on the very outer edge of the application, within the HTTP handler and is known as Centralised Error Handling.

Whether or not we choose to implement Centralised Error Handling in our application, a good rule of thumb when working with Exceptions is 'Throw early , catch late'.

Custom Exceptions

Clarity is King when it comes to coding. Custom Exceptions allow us to be really specific about what's going wrong in a given instance - making unexpected behaviours easier to understand. We can create Custom Exceptions by extending the Exception class (or one of its subclasses).

When creating a Custom Exception we can choose whether or not to pass an Exception message string as a parameter.

Using our divider function as an example again, here are some custom exception ideas:
No message:

class DivisionException() : ArithmeticException()                 
// remember we can create our Exception from any Exception subclasses

fun main() {  
   throw DivisionException()
}

versus with Message:

class DivisionExceptionWithMessage(message: String) : Exception(message)

fun main() {  
   throw DivisionExceptionWithMessage(“You can add any message you like here and the message can be different in every instance where it is thrown”)
}

Custom Exceptions can be particularly useful when we want to observe unexpected behaviour specific for business logic - where the standard exceptions available don't quite describe the problem as we would like.

Our divider function, now using our custom exception (with message):

fun divider(a: Int, b: Int): Int {
    if (b == 0 || a == 0) {
        throw DivisionExceptionWithMessage("you cannot divide by zero")
    }
    return a/b
}

fun main() {
 try {divider(2, 0)}
    catch (e: DivisionExceptionWithMessage) {
       e.printStackTrace()
    }
}

When we run the main function above, we get the following response in the IDE console:

Stack Trace

The above image is an example of a Stack Trace. The Stack Trace is a list of the method call hierarchy. It shows us what the problem is, where to find its origin and how it was called.

To break down this Stack Trace:
Line 1 - Exception type and message - nice and clear thanks to custom Exception.
Line 2 - Points to the divider function, where the Exception was thrown.
Line 3 - Shows the exact line where the divider function was called.
Line 4 - Indicates the entry point to the application and where the Stack Trace starts.

Note that because we followed the 'Throw early, catch late' philosophy, we got a full stack trace and this helps us get the full picture of where and why our Exception was triggered.

Things to Consider

🔑 Security
We must carefully consider the information we disclose in custom Exception messages. Overly revealing messages will leave your application vulnerable to hackers and cyber criminals. If in doubt, an exception with no message is preferred.

Application speed
Throwing exceptions can slow down your application - something to bear in mind.

Real world Exception handling
In the examples in this post, we handle our Exceptions by printing the full stack trace to the console and/or returning a safe, default value. Whilst this approach is fine for small applications and exercises, a better approach for real applications would be one/all of the following:

Log the message to somewhere like Datadog where we can monitor and review our application
If the Exception occurred in a Front End application we could return an error response to the user, requiring them to submit another set of numbers
If the Exception occurs in an API, the Exception could be returned as a Http Status code - eg 400 Bad Request

Handy tools
Result
Kotlin's Result is an exception wrapper which is designed to catch exceptions as values. It returns either a successful outcome (Result.success(value)) or a failure (Result.failure(exception)). This allows us to handle operations that might throw exceptions without using try/catch.
Result4k, Arrow
Using the Result4k or Arrow libraries, we can replace exceptions with expected named error values which allows us to bypass the need for try catch blocks.

Checked / Unchecked Exceptions
If you have a Java background, you may have heard of checked and unchecked exceptions. In Kotlin, all exceptions are unchecked — which means it's up to us to decide what to handle 😎.