In his article about Kotlin exceptions, Roman Elizarov says:

val number = "123".toInt()

In the above code it is pretty clear that a failure of

toInt

function is a bug in the code and so it throws a

NumberFormatException

if the given string does not represent an integer. But what if some

string

came from a user input field and application logic shall deal with invalid input by replacing it with a default value?

The solution is to use

val number = string.toIntOrNull() ?: defaultValue

, which is explained with:

It indicates an error through its result value, using

null

in this particular case.

I understand the logic behind this, but later he writes the following function:

fun updateOrderQuantity(orderId: OrderId, quantity: Int) {
    require(quantity > 0) { "Quantity must be positive" }
    val order = loadOrder(orderId)
    order.quantity = quantity
    storeOrder(order)
}

What if the quantity came from a user input? Should I write a new function

updateOrderQuantityOrNull

? Is it idiomatic for a function to return a nullable value but to throw an exception on an I/O error?

I’d argue you at least don’t want to let a kotlinx.serialization exception bubble up, since it leaks an implementation detail (what happens if you switch the serialization library later). If you go the exception route, you should catch and throw your own exception.

The null value pattern only works when there is a limited amount of possible reasons for the function to fail

I’d also add that it works in cases when you don’t care why it failed. That’s why it may be good to supply both.

Thank you. And what about using a sealed class to express what failed? But maybe this is not appropriate in case of a serialization exception and, like @Landry Norris said, I should rethrow my own exception?

A sealed class is a viable choice. It can get a little verbose (can’t directly return a result, but a Success wrapper or a Failure wrapper).

Another question to ask in this situation is: where is the

updateOrderQuantity

being called, and if the

quantity

were validated in the UI, would that fix the issue in that function? Assuming

updateOrderQuantity

is part of the “repository layer” of you app and is making some change (submitting an API call, updating the local DB, etc), then you should generally want to be pretty strict about your validation checks. Don’t trust anything passed in, make the check yourself. Even if the UI validates the

quantity

in the UI and shows the user a nice error message, you still want the check so that things still get processed properly if that same function is called from some other point in your application, which may not have that same UI validation. As for how exactly to model your “service calls”, it basically comes down to whether you want to set up your app to handle exceptions, or to branch the logic with result types (a null return value being one type of “result”, but you can use more explicit things like sealed classes, the built-in Result class, Arrow, etc.). As a general rule, exceptions are easy to implement and pretty easy to handle (you can handle errors centrally without a bunch of intermediate steps) but are also easy to mess up or forget to handle. A centralized error-handler can also handle a bunch of different types of exceptions without necessarily needing to know the specific error that occurred (just show a simple message like “oops, something went wrong”). Result types help force you to handle the errors, but can get a bit cumbersome as they need to be handled through all the intermediary layers between the UI and the service call. They give you a lot of insight into what went wrong, a lot of control on recovering from those errors, and generally a greater guarantee that you app is. behaving as you expect. But again, that comes at the cost of more boilerplate and needing to be more intentional about how you develop your app.

From my understanding, it is up to me to make a choice between a sealed class or an exception, depending on the layer the code is working on and the verbosity I want to bring to my code. Thank you all for your help!

I’d recommend making a choice for the project and sticking with it throughout to reduce confusion.

Noted!