Forem: Florian Röser

Kotlin for Java Developers (Part 3)

Florian Röser — Wed, 29 Jan 2025 08:11:54 +0000

This is part 3 of a series, that outlines the most common hints and quirks a java developer might face when switching to kotlin. This article handles following topics:

Forgetting Default Arguments And Parameters
Using for Loops Instead Of forEach
Using lazy Initialization
Reference: Kotlin Coding Conventions

If you are interested in the previous articles, here you can find Part 1 and Part 2

Forgetting Default Arguments And Parameters

In contrast to Java, Kotlin allows the definition of default values for function parameters, eliminating the need for overloading functions with different parameter counts. This is especially useful when a function has many parameters that often take the same value.

Default Function Parameters

Java way:

public void greet(String name, String greeting) {
  System.out.println(greeting + " " + name);
}

/**
 * Overloaded "greet" method with default value
 */
public void greet(String name) {
  greet(name, "Hello");
}

Kotlin way:

with default value for the parameter greeting

fun greet(name: String, greeting: String = "Hello") {
  println("$greeting $name")
}

example calls:

greet("Alice") // Hello Alice
greet("Bob", "Hi") // Hi Bob

This approach removes duplicated code and reduces the method count, especially when the method has many parameters.

Default Constructor Arguments

Default values are not only allowed in function parameters, but also in constructor arguments. This is especially helpful when you need to create objects with optional parameters.

Java way:

public class Person {
  private String name;
  private int age;

  public Person(String name) {
    this(name, 42);
  }

  public Person(String name, int age) {
    this.name = name;
    this.age = age;
  }

  public void introduce() {
    System.out.println("Hi, I'm " + name + ", and I'm " + age + " years old.");
  }
}

Usage in Java:

public class Main {
    public static void main(String[] args) {
        Person person1 = new Person("Alice");  // Uses default age 42
        Person person2 = new Person("Bob", 25);  // Uses custom age 25

        person1.introduce();  // Outputs: Hi, I'm Alice, and I'm 42 years old.
        person2.introduce();  // Outputs: Hi, I'm Bob, and I'm 25 years old.
    }
}

Instead of overloading the constructor, you can use default values in Kotlin:

Kotlin way:

class Person(val name: String, val age: Int = 42) {
    fun introduce() {
        println("Hi, I'm $name, and I'm $age years old.")
    }
}

Usage in Kotlin:

val person1 = Person("Alice")  // Uses default age 42
val person2 = Person("Bob", 25)  // Uses custom age 25

person1.introduce()  // Outputs: Hi, I'm Alice, and I'm 42 years old.
person2.introduce()  // Outputs: Hi, I'm Bob, and I'm 25 years old.

Using `for` Loops Instead Of `forEach`

In Kotlin, you can use the higher-order function forEach to iterate over collections, however, Kotlin's for loop is often more idiomatic and can be a better choice in some cases. Understanding when to use which loop is crucial for writing clean Kotlin code.

The `for` loop in Kotlin

Basic for loop example using a range over a collection:

val numbers = listOf(1, 2, 3, 4, 5)

for (number in numbers) {
    println(number)
}

Basic `forEach` loop in Kotlin

The forEach function is part of Kotlin's functional programming features, it takes a lambda function as an argument and executes it on each element of the collection:

val numbers = listOf(1, 2, 3, 4, 5)

numbers.forEach { number -> println(number) }

The element is available as it by default, if you don't specify a name for the lambda parameter:

val numbers = listOf(1, 2, 3, 4, 5)

numbers.forEach { println(it) }

When to use `for` loops

If you're performing simple iterations and don't need the additional power, the for loop is usually the better choice, especially for performance reasons. forEach involves function-calls (higher-order functions), which can incur slight overhead, while a for loop is generally more efficient.

Example (Performance Consideration):

val numbers = listOf(1, 2, 3, 4, 5)

var sum = 0
for (number in numbers) {
    sum += number
}
println(sum)

In this case, the for loop does not involve any additional function calls, making it more efficient.

Example (Using break and continue):

The for loop has built-in support for break and continue statements, allowing you control over the flow more easily.

val numbers = listOf(1, 2, 3, 4, 5)

for (number in numbers) {
    if (number == 3) {
        break // exit the loop when number is 3
    }
    println(number) // Will print 1, 2
}

When to use `forEach` loops

1. Cleaner and more expressive for functional style programming

The forEach function is more idiomatic when you're working with a functional programming style or when you want the code to be more declarative and expressive. If you don't need break or continue, the forEach can be the more readable and elegant choice, especially for smaller functions.

Example (Functional Style):

val numbers = listOf(1, 2, 3, 4, 5)
numbers.forEach { println(it) }

2. When you want to use lambdas for more complex operations

forEach allows you to use lambdas for more complex operations, such as filtering, mapping, or reducing elements.

Example (Using Lambda):

val numbers = listOf(1, 2, 3, 4, 5)

numbers.forEach {
    val squared = it * it
    println("The square of $it is $squared")
}

3. Functionally chaining operations

When working with collections, forEach can be more intuitive when you're chaining multiple operations together like map, `filter, etc.

Example (Chaining Operations):

`kotlin
val numbers = listOf(1, 2, 3, 4, 5)

numbers.filter { it % 2 == 0 }
.forEach { println(it) } // Prints only even numbers
`

Performance considerations

While forEach is more convenient and expressive, there is a small performance overhead due to the lambda function calls. The difference in performance between those two is usually minimal for small collections, however, if performance is critical, especially with large collections, for loops might be preferable.

Using `lazy` Initialization

Another Kotlin-feature is the lazy initialisation, which allows to defer the creation of an object or the evaluation of an expression until it's actually needed. This can be useful to improve performance of your application by delaying expensive computations until they are actually needed. Kotlin's lazy initialisation is thread-safe by default.

Example: Lazy Initialization

`kotlin
val name: String by lazy {
println("Initializing name")
"Kotlin"
}

fun main() {
println("Before accessing name")
println(name)
println("After accessing name")

// Output:
// Before accessing name
// Initializing name
// Kotlin
// After accessing name

}
`

Example: Lazy Initialization for Expensive Objects

Example of lazy database connection

`kotlin
class Database {
init {
println("Connecting to database...")
}

fun queryData(): String {
    return "Database Data"
}

}

class DataFetcher {
val database: Database by lazy { Database() } // only created when accessed

fun fetchData() = database.queryData()

}

fun main() {
val dataFetcher = DataFetcher()
println("Before fetching data")
println(dataFetcher.fetchData()) // the database-connection is created here
println("After fetching data")

// Output:
// Before fetching data
// Connecting to database...
// Database Data
// After fetching data

}
`

Notice that the database-connection is only created when the database property is actually accessed.

Other use-cases

Other use-cases for lazy initialization include:

Singletons
Heavy computation
Resources, such as database connections, large datasets or API clients
Optional features, that might not be used in every execution path

Kotlin Coding Conventions

Kotlin has dedicated a whole page to coding conventions, which you can find here.
Please make yourself familiar with these conventions, as they are widely accepted in the Kotlin community.

Kotlin for Java Developers (Part 2)

Florian Röser — Mon, 27 Jan 2025 08:58:12 +0000

Kotlin for Java Developers (Part 1) covers

Data classes
Null safety
Immutability by default

This part continues on the key differences that a Java developer should be aware of when switching from Java to Kotlin. Part 2 of the series covers

Using new Keyword
Utilise Extension Functions
Use when Instead Of if Or switch

Using `new` Keyword

This is a rather small section, but I've confusion about this topic several times. In Kotlin, you don't need the new keyword to instantiate an object. The object creation is simpler, as Kotlin automatically understands that you want to create a new instance of a class.

Java way:

MyClass myClass = new MyClass();

Kotlin way:

val myClass = MyClass()

You simply call the class constructor directly, like you would with a function call.
val is used to declare an immutable variable that will hold the reference to the object (see immutability in part 1).

Utilise Extension Functions

Extension functions are a powerful feature, which allows you to add new functionality to existing classes without modifying their source-code! This is particularly useful when you need to enhance the capabilities of libraries or classes that you don't control, or when you want to avoid subclassing or writing utility classes.

Example 1: Extension functions on strings

Java way:
In Java, you might create a utility class with a static method to add functionality to a class.

public class MyStringUtils {
  public static boolean isValidEmail(String email) {
    return str != null && str.contains("@"); // Simplified email validation
  }
}

to use this, you would have to call it as a static method:

String email = "test@example.com";
boolean isValid = MyStringUtils.isValidEmail(email);

Kotlin way:
In Kotlin, you can add a new function to the String class to check if a string is a valid email address.

fun String.isValidEmail(): Boolean {
    return this.contains("@") // Simplified email validation
}

or even shorter:

fun String.isValidEmail() = this.contains("@")

The this keyword refers to the object the extension function is called on. You can call this function on any
String object:

val email = "test@example.com"
val isValid = email.isValidEmail() // direct call on the string object to the extension function

This makes the code much cleaner and more readable as it avoids the boilerplate code of utility classes or inheritance.

Example 2: Extension functions on collections

E.g. if you want a filter function to only retrieve odd numbers from a list.

Java way:

import java.util.List;
import java.util.stream.Collectors;

public class MyListUtils {
    public static List<Integer> getOddNumbers(List<Integer> numbers) {
        return numbers.stream()
                      .filter(n -> n % 2 != 0)
                      .collect(Collectors.toList());
    }
}

and you would call it like this

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9);
List<Integer> oddNumbers = MyListUtils.getOddNumbers(numbers);

Kotlin way:

fun List<Int>.getOddNumbers() = this.filter { it % 2 != 0 }

and you would call it directly on the list:

val numbers = listOf(1, 2, 3, 4, 5, 6, 7, 8, 9)
val oddNumbers = numbers.getOddNumbers()

Why use extension functions?

Cleaner code: Extension functions allow you to write code as if the function is part of an existing class, making you code-base look more natural and reduce boilerplate code.
Reusability: You can write reusable functionality outside the class itself

References

Kotlin documentation on extension functions

Use `when` Instead Of `if` Or `switch`

The when expression in Kotlin can be thought of as an advanced version of the switch statement in Java, that is much more powerful and can also replace the if-else statement. A key difference is, that the when expression is not limited to checking the equality as in Java, but can handle a wide range of conditions, like types, ranges and even arbitrary expressions.

Example 1: Using `when` instead of `if-else`

Java way:

int x = 2;
String result;

if (x == 1) {
    result = "One";
} else if (x == 2) {
    result = "Two";
} else if (x == 3) {
    result = "Three";
} else {
    result = "Unknown";
}
System.out.println(result);

Kotlin way:

val x = 2
val result = when (x) {
    1 -> "One"
    2 -> "Two"
    3 -> "Three"
    else -> "Unknown"
}
println(result)

Example 2: Using `when` instead of `switch`

Again the same java example:

int x = 2;
String result;

switch (x) {
    case 1:
        result = "One";
        break;
    case 2:
        result = "Two";
        break;
    case 3:
        result = "Three";
        break;
    default:
        result = "Unknown";
}
System.out.println(result);

And the Kotlin equivalent:

val x = 2
val result = when (x) {
    1 -> "One"
    2 -> "Two"
    3 -> "Three"
    else -> "Unknown"
}
println(result)

In Kotlin, there is no need for break statements, as the when expression automatically breaks after the first match.

Example 3: Using `when` with ranges

Kotlin's when expression can be used with ranges or collections:

val x = 5
val result = when (x) {
    in 1..10 -> "Between 1 and 10"
    !in 11..20 -> "Outside 11 - 20"
    else -> "Other"
}

Example 4: Checking Types

You can also use when to check the type of an unknown object, similar to instanceof in Java:

fun checkType(obj: Any): String {
    return when (obj) {
        is String -> "String"
        is Int -> "Int"
        is Double -> "Double"
        else -> "Unknown"
    }
}

println(checkType("Hello")) // Prints "String"
println(checkType(42)) // Prints "Int"
println(checkType(3.14)) // Prints "Double"
println(checkType(true)) // Prints "Unknown"

References:

Kotlin documentation on when expression

Interested in the next article?
Here is Part 3 of the series.

Kotlin for Java Developers (Part 1)

Florian Röser — Mon, 27 Jan 2025 07:22:22 +0000

Java is the top dog among programming languages, and so I've seen several times java developers making the same kind of mistakes when using Kotlin.
Don't understand me wrong, it's not that these are bugs, but rather "code smells" when developers tend to develop in Kotlin as they are used to do in Java, not making use of Kotlin features.

This article should make you aware of the code smells I see most often and how you would ideally implement them in a "Kotlin way".

Part 1 of the series will cover

Make use of data classes
Leveraging Null Safety
Immutability By Default

(Disclosure: the header image is created using Dall-E as you can see on the broken typing in the background)

Make use of data classes

This is topic that might vanish soon since I experience more and more Java developers also having experience with record classes. Nonetheless, there are some differences between Java records and Kotlins data class.

Java way:

public class Person {
  private String name;
  private int age;

  public Person(String name, int age) {
    this.name = name;
    this.age = age;
  }
  // Getters, setters, ...
}

or as a record:

public record Person(
    String name,
    int age
) {
}

Kotlin way:

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

There are some differences between Java record and Kotlin data class that you might want to know about.

Both, Java record and Kotlin data class are immutable data carriers.
In Java, the fields are implicitly final and cannot be modified after construction, while in Kotlin, you can choose whether you want to make the fields mutable or not by using val or var.
Another difference is that record classes in Java are implicitly final and sealed, which means that they cannot be extended, while in Kotlin you can extend data classes.
Also in Kotlin you can override the equals, hashCode and toString methods, which is not possible in Java.
Kotlin provides a copy method out of the box, which is not available in Java.

Some examples:

Copying objects in Java

Person p2 = new Person(p1.getName(), p1.getAge());

Kotlin:

val p2 = p1.copy(age = 42)

Or destructuring declarations in Java:

String name = p1.getName();
int age = p1.getAge();

Kotlin:

val (name, age) = p1
println(name) // "John"
println(age) // 42

References

Leveraging Null Safety

In my opinion, null-safety in Kotlin is one of the most powerful features. It's a game changer and can save you a lot of time and headaches.
In Kotlin, null safety is built into the type system, which makes it easier to avoid null-related runtime errors.

1. Nullable Types

In Kotlin, nullable types are explicitly declared. This means you can have a variable that might hold a null value, but you must specify it explicitly in the declaration.

Non-nullable types (default behaviour)

By default, all types in Kotlin are non-nullable, this means, that a variable cannot hold a null value.

val name: String = "John" // non-nullable
name = null // Compilation error!

Nullable types

To declare a variable that can hold a null value, you have to use the ? operator.

val name: String? = null // nullable

2. Safe Calls

A powerful feature is the safe call operator ?.. It allows you to safely call a method or access a property without throwing a NullPointerException.

Example

val name: String? = null
println(name?.length) // Prints null instead of throwing an exception

The ?. operator checks if the object is null and if it is, it returns null immediately, otherwise it proceeds to call the method or access the property. If the object is null, the entire expression evaluates to null.

3. Elvis Operator (`?:`)

The Elvis operator ?: is a shorthand for returning a default value if the expression to the left of the operator is null.

val name: String? = null
val length = name?.length ?: 0 // if name is null, default is 0
println(length) // 0

4. The `!!` Operator (Not-Null Assertion)

You can use the !! operator to tell the compiler that the value is not null. If the value is null, it will throw a NullPointerException.

val name: String? = null
println(name!!) // Throws NullPointerException

HINT:
It's not recommended to use this !! operator because it defeats the purpose of null safety.

5. Nullability in Function Parameters

When you define a function, you can specify whether a parameter can be null or not. In that case, the caller has to handle it.

fun greet(name: String?) {
    println("Hello, ${name ?: "Guest"}")
}
greet(null) // Hello, Guest
greet("Alice") // Hello, Alice

6. Safe Casts (`as?` operator)

There is a safe cast operator as? that returns null if the cast is not possible.

val obj: Any = "Kotlin"
val str: String? = obj as? String
println(str) // Prints "Kotlin"

val num: Int? = obj as? Int
println(num) // Prints null

7. Null safety in Lambdas

You can also use the null safety features in lambdas and higher functions:

val list: List<String?> = listOf("Kotlin", null, "Java")
val lengths = list.map { it?.length ?: 0 }
println(lengths) // Prints [6, 0, 4]

8. Utilize `let` Function

The let function is a scope function that allows you to execute a block of code on a non-null object. It's typically used for executing code on a nullable object in a safe way.

Example also with default values:

val name: String? = null

val result = name?.let {
    println("Name is not null: $it")
    it.length // this won't be executed because name is null
} ?: "Default value"

println(result) // Prints "Default value"

9. Best Practices

Avoid using the !! operator
Use save calls and the Elvis operator to safely handle nullable types and provide default values
Use nullable types thoughtfully and only when necessary

References:

Kotlin Null Safety

Immutability By Default

Kotlin strongly encourages a functional programming style!
For a functional programming style, immutability plays a crucial role in avoiding bugs, specially in multi-threaded applications.

Maybe I'm going to write a separate article about functional programming in Kotlin or Java, but for now, let's focus on immutability.

Kotlin inherently favors immutable objects over mutable ones. This leads to simpler, more predictable code, especially in a concurrent environment.

1. Immutable Variables by Default (`val`)

In Kotlin, variables are immutable by default when declared using the val keyword. This quite close to declaring a final variable in Java, but with a few key differences:

A val variable in Kotlin is effectively read-only - the value assigned to it cannot be changed after initialisation.
However, if the value is an object, mutating the properties of that object is still possible, unless those properties are declared as val themselves.

*Example:

val name = "Kotlin"
// name = "Java" // Compilation error!

Difference from Java:
In Java, we use the final keyword to ensure that a variable can't be reassigned, but the object it points to can still be mutable. The key difference in Kotlin is that immutability extends to variables by default, encouraging a more predictable and safe design for the entire application.

Example of a mutable variable:
Using the var keyword in Kotlin allows you to reassign the variable.

var age = 42
age = 43 // No compilation error

HINT:
Kotlin encourages to use val over var whenever possible to ensure immutability.

2. Immutable Collections

It's also encouraged to work with immutable collections by default. Immutable collections prevent any modification after creation, for example, if you create a List using listOf(), it cannot be changed, no elements can be added, removed ore altered.

val numbers = listOf(1, 2, 3)
numbers.add(4) // Compilation error!

If you need to modify a collection, you can use mutableListOf() or other mutable collection types.

val mutableNumbers = mutableListOf(1, 2, 3)
mutableNumbers.add(4) // Allowed

Differences from Java:
In Java, collections, such as ArrayList are mutable by default, which means that the elements can be modified freely.

3. Immutable Data Classes

Kotlin's data class are immutable by default. When defining a data class, properties are typically declared as val, making the class immutable. This makes the classes great for value objects, especially when working with APIs, database records, or any other scenario where object's state should not change after creation.

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

val person = Person("Alice", 42)
person.name = "Bob" // Compilation error!

4. Immutability in Sealed Classes

Kotlin's sealed classes can also be immutable, and they work well with immutable data models. Sealed classes are often used to represent restricted class hierarchies, like states or responses, and their immutability ensures that the state or result doesn't change unexpectedly.

sealed class Response
data class Success(val data: String) : Response()
data class Error(val message: String) : Response()

val response: Response = Success("Data loaded successfully")
response = Error("Something is wrong") // Compilation error! This would require reassignment.

Interested? Some more Kotlin features are covered in Part 2 of the series

Error Handling Bad Practices

Florian Röser — Tue, 03 Sep 2024 09:19:36 +0000

This article is a follow-up on my previous 3-step-error-handling article.

In this article I want to show some bad practices in error handling and maybe some quick-fixes, if you stumble
across them in your codebase.

Disclaimer, this blog-post is only a personal opinion and you will need to adjust the recommendations to your specific use-case.

I will handle these antipatterns:

1. Swallowing exceptions
2. Over-logging exceptions
3. Catch generic exceptions
4. (Over-)using checked exceptions
5. Using Exceptions for Control Flow

1. Swallowing exceptions

I regularly stumble across code-bases where exceptions are silently ignored. Maybe the developer was in a hurry or wanted to handle the error cases later on? Anyway, this is a bad practice because if the error occurs:

the user will not get any feedback and might think that the operation was successful.
there is no stacktrace or error-message to investigate.
sometimes there is not even a proper log-entry, making it almost impossible to detect the error.

Bad Example:

  /**
   * Reads some data from another service or repo and returns it.
   * The repo might throw an exception, but we don't care.
   */
  public Mono<String> getHello() {
    try {
      return helloRepository.getHello()
          .map("Hello %s"::formatted);
    } catch (Exception e) {
      // do nothing
      return Mono.just("Hello World");
    }
  }

In this example we might wonder why some users complain about not getting the correct hello-message, but we don't see any errors, we might think that the users are just confused.

Option 1 - Keep the try-catch and handle the error

Handle the error where it occurs, e.g. already in the Repository if possible.
If you need to handle it here, at least log the error and return a proper error-message.

Minimal refactoring

log the error (optionally also the stacktrace)
return a proper error-message

  public Mono<String> getHello() {
    try {
      return helloRepository.getHello()
          .map("Hello %s"::formatted);
    } catch (Exception e) {
      log.error("Error reading hello data from repository - {}", e.getMessage(), e);
      return Mono.error(new RuntimeException("Internal error reading hello data %s".formatted(e.getMessage()), e));
    }
  }

NOTE:

This might break upstream code since you are now returning an error instead of some default value.

Option 2 - Proper reactive stream refactoring

Better would be to handle the error inside the reactive stream api

  public Mono<String> getHelloHandling() {
    return helloRepository.getHello()
      .map("Hello %s"::formatted)
      // wrap the exception in a RuntimeException with a meaningful message
      .onErrorMap(e -> new RuntimeException("Internal error reading hello data from HelloRepository` %s".
          formatted(e.getMessage()), e));
  }

1b. Swallowing exceptions - with a reactive stream

The pattern from example one also appears in reactive streams:

  public Mono<String> getHello() {
    return helloRepository.getHello()
        .map("Hello %s"::formatted)
        // do nothing on error, just return a default value
        .onErrorReturn("Hello world");
  }

That looks very nice and clean, right? But we will not be able to detect that the error is thrown in the repository!
If there is a default-value, at least an error-log should be written.

Mitigation

As in the previous example we are wrapping the exception in another exception, this time in a custom exception that even makes it easier to detect the specific place where that exception is thrown

  public Mono<String> getHello2() {
    return helloRepository.getHello()
        .map("Hello %s"::formatted)
        .onErrorMap(
            e -> new CustomException("Error reading hello-data from repository - %s".formatted(e.getMessage()), e));
  }

2. Over-logging exceptions

The very opposite of silently dropping exceptions is logging the same exception multiple times, e.g. in the function it occurs, then pass it on to the calling function where again the stacktrace is printed, and in the caller of that again...
This is a bad practice because it confuses the logs with hundreds or thousands of lines of stacktraces without providing any additional meaning.

In my worst example I found the same stacktrace five times in the logs with no meaningful message at all.

Bad Example:

The controller:

@RestController
@AllArgsConstructor
@Slf4j
public class HelloController {

  private final HelloService helloService;

  @GetMapping("/hello")
  public Mono<ResponseEntity<String>> hello() {
    return helloService.getHello()
        .map(ResponseEntity::ok)
        .defaultIfEmpty(ResponseEntity.notFound().build())
        .onErrorResume(e -> {
          log.error("Error:", e);
          return Mono.error(e);
        });
  }
}

And in the Service:

@Service
@AllArgsConstructor
@Slf4j
public class HelloService {

  private final HelloRepository helloRepository;

  /**
   * Reads some data from another service or repo and returns it.
   */
  public Mono<String> getHello() {
    return helloRepository.getHello()
        .map("Hello %s"::formatted)
        .onErrorResume(e -> {
          log.error("Error:", e);
          return Mono.error(e);
        });
  }
}

... and probably in some more places...

Mitigation

This is explained in my previous article 3-step-error-handling, therefore I will not show the code here again, but rather a recommendation:

Have a global error-handler that logs the error and returns a proper error-message to the user.
In the code, avoid the stacktrace but
- wrap the exception in a custom exception or runtime exception with a meaningful message
- log the error-message (not the whole stacktrace)
- log the stacktrace only in the global error-handler

3. Catch generic exceptions

Catching generic exceptions like Exception or Throwable can lead to unintended behaviour and make debugging quite difficult. It's better to catch specific exceptions.

Bad Example

  public Mono<String> getHello() {
    try {
      return helloRepository.getHello();
    } catch (Exception e) {
      log.error("Error while fetching hello data", e);
      return Mono.empty();
    }
  }

Mitigation

Catch specific exceptions to handle different error scenarios appropriately.

  public Mono<String> getHello() {
    try {
      return helloRepository.getHello();
    } catch (SQLException e) {
      return Mono.error(new HelloDataException("Database error while getting hello-data - %s".formatted(e.getMessage()), e));
    } catch (IOException e) {
      // maybe perform a retry?
      return Mono.error(new HelloDataException("IO error while getting hello-data - %s".formatted(e.getMessage()), e));
    }
  }

and the equivalent using the reactive stream api

  public Mono<String> getHello() {
    return helloRepository.getHello()
        .onErrorMap(SQLException.class, e -> new HelloDataException("Database error while getting hello-data - %s".formatted(e.getMessage()), e))
        .onErrorMap(IOException.class, e -> new HelloDataException("IO error while getting hello-data - %s".formatted(e.getMessage()), e));
  }

4. (Over-)using checked exceptions

In my opinion, checked exceptions where a mistake in Java, they are not very useful and often lead to bad practices and cluttered code.

Bad Example

public void someMethod() throws IOException, SQLException {
  // some code that might throw an exception
}

With checked exceptions you have to deal with them in the calling code, which makes it harder to use other patterns, e.g. functional programming or reactive streams or in spring the global error-handler.

Exception:
Checked exceptions are useful e.g. in library code, where you want to force the user to handle the exception.

Mitigation

Use unchecked exceptions for scenarios where the caller cannot reasonably be expected to recover.

public void someMethod() {
  try {
    // some code that might throw an exception
  } catch (IOException | SQLException e) {
    throw new RuntimeException("An error occurred - %s".formatted(e.getMessage()), e);
  }
}

5. Using Exceptions for Control Flow

Using exceptions for control flow makes the code hard to understand and can lead to performance issues.

Bad Example

try {
  int value = Integer.parseInt("abc");
} catch (NumberFormatException e) {
  // handle the case where the string is not a number
}

Mitigation

Use a regular flow control mechanism like an if-statement.

String value = "abc";
if (value.matches("\\d+")) {
  int number = Integer.parseInt(value);
} else {
  // handle the case where the string is not a number
}

Conclusion

In this article I showed some bad practices in error handling and how to mitigate them.
I hope you found this article helpful and maybe you can use some of the recommendations in your codebase and in your next refactoring.

Some, not so new, thoughts on error handling in Spring and Java

Florian Röser — Fri, 28 Jun 2024 18:54:52 +0000

Update:
Adde more examples

Recently I had an experience about a confusing code and inconsistent error responses in a rest-service, written in Java and SpringBoot.
That led me to some experiments and to recap what I learned from programming in GoLang and reading Robert C. Martin's book "Clean Code" which has a whole section dedicated on error handling :D

Bad Examples

I regularly stumble accross code that logs the stacktrace at every step in the code, sometimes even without a proper log-message. This results in multiple times the same stacktrace.

The controller:

@RestController
@AllArgsConstructor
@Slf4j
public class HelloController {

  private final UserService userService;

  @GetMapping("/hello")
  public Mono<ResponseEntity<User>> hello() {
    return userService.getUser()
        .map(ResponseEntity::ok)
        .defaultIfEmpty(ResponseEntity.notFound().build())
        .onErrorResume(e -> {
          log.error("Error:", e);
          return Mono.error(e);
        });
  }
}

And in the Service:

@Service
@AllArgsConstructor
@Slf4j
public class UserService {

  private final UserRepository userRepository;

  /**
   * Reads some data from another service or repo and returns it.
   */
  public Mono<User> getUser() {
    return userRepository.getUser()
        .map("Hello %s"::formatted)
        .onErrorResume(e -> {
          log.error("Error:", e);
          return Mono.error(e);
        });
  }
}

Makes very large logs with thousands of log-lines for one error, just because of multiple times that the stacktrace was printed.
Confuses the error-investigation, was it one exception? Multiple ones? Which is the correct one?
Missing error-messages? Without a meaningful error message it's very hard to find the reason why the error occured.

My Rule

So what I came up with is nothing but new, this is just a recap and something I consider a good practice when I do my reviews on someone elses code.
It boils down to one rule and three steps when you handle an error (or exception).

The rule:
"Handle the error where it occurs."

The three steps

Log a meaningful error message (and the exception message) once, but only once!
Assess whether you can recover from here, then handle it here and continue without passing on exceptions or error codes.
Fail Fast: If you cannot recover, throw an "unchecked", specific, new exception and with that terminate the request, do not propagate the caught exception. Handle the unchecked exception in a global error handler.

Here in more detail and reasoning.

1. Log a meaningful message

It is crucial, to think extensively what to log so someone investigating an error can directly see what happened, where and why. In most cases this should be done without printing the whole stacktrace, if you need to print the stacktrace, than print it preferably in debug logs, so if neccessary the debug-mode can be activated to see a more detailed picture.
Avoid printing multiple logs for the same error! This obfuscates the code, makes it hard to detect where exactly the error occurred and what the original reason was.

2. Assess whether you can recover

Catch the exception where it occurs, then check if you can recover from that exception, e.g. you can continue without that information or perform a retry for a connection. This is crucial to keep the code clean and have your logic there where you need it.
If you can recover, then do it and don't pass on the exceptions or error codes, error-codes are anyway a bad idea as mentioned in Robert C. Martin's book.

3. Fail Fast

If you cannot recover, then don't just propagate the caught exception.
Instead, wrap it in a specific, new, "unchecked" exception that will terminate the current request.
This helps to see very exactly where the error appeared, it helps to keep your code clean by not having to handle the exception in every method in the stacktrace. Instead use a global error handler to catch those specific exceptions and return a meaningful response to the client.

My custom exception

public class UserNotFoundException extends RuntimeException {
  public UserNotFoundException(String message, Throwable cause) {
    super(message, cause);
  }
}

Wrapping the original exception

  public Mono<User> getHello() {
    return userRepository.getUser()
        .onErrorMap(e -> new UserNotFoundException("Error while fetching user data from repository", e));
  }

And finally taking care of the exceptions in the global error-handler

@RestControllerAdvice
public class GlobalErrorHandler {

  /**
   * Handling unexpected, non-specific exceptions
   */
  @ExceptionHandler(Throwable.class)
  @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
  public ErrorResponse handleUncaughtExceptions(Throwable t) {
    log.error("Uncaught exception occurred: {}", t.getMessage());
    log.debug("Stacktrace", t);
    return new ErrorResponse(t.getMessage(), "ERR_500");
  }

  /**
   * Handle UserNotFoundException
   */
  @ExceptionHandler(UserNotFoundException.class)
  @ResponseStatus(HttpStatus.NOT_FOUND)
  public ErrorResponse handleUserNotFoundException(UserNotFoundException e) {
    log.warn("User could not be found in the database, request cannot be processed - {}", e.getMessage());
    return new ErrorResponse("Unable to find user", "ERR_404");
  }
}

Using this, will keep all upstream methods clean, because they don't have to implement try-catch and error-handling again and again, but can focus on the main task and logic.

This also reduces the amount of log-lines printed for each error and makes finding the root-cause much easier.

Summary

Using this three-step method helps you to keep your code clean, to have meaningful logs that improve investigation if something fails and avoids overboarding log entries that obfuscate the main issue.

If you want further reading on Java Exception Handling, you may enjoy the Error Handling Bad Practices article.

Forem: Florian Röser

Kotlin for Java Developers (Part 3)

Forgetting Default Arguments And Parameters

Default Function Parameters

Default Constructor Arguments

Using for Loops Instead Of forEach

The for loop in Kotlin

Basic forEach loop in Kotlin

When to use for loops

When to use forEach loops

1. Cleaner and more expressive for functional style programming

2. When you want to use lambdas for more complex operations

3. Functionally chaining operations

Performance considerations

Using lazy Initialization

Example: Lazy Initialization

Example: Lazy Initialization for Expensive Objects

Other use-cases

Kotlin Coding Conventions

Kotlin for Java Developers (Part 2)

Using new Keyword

Utilise Extension Functions

Example 1: Extension functions on strings

Example 2: Extension functions on collections

Why use extension functions?

References

Use when Instead Of if Or switch

Example 1: Using when instead of if-else

Example 2: Using when instead of switch

Example 3: Using when with ranges

Example 4: Checking Types

References:

Kotlin for Java Developers (Part 1)

Make use of data classes

References

Leveraging Null Safety

1. Nullable Types

2. Safe Calls

3. Elvis Operator (?:)

4. The !! Operator (Not-Null Assertion)

5. Nullability in Function Parameters

6. Safe Casts (as? operator)

7. Null safety in Lambdas

8. Utilize let Function

9. Best Practices

References:

Immutability By Default

1. Immutable Variables by Default (val)

2. Immutable Collections

3. Immutable Data Classes

4. Immutability in Sealed Classes

Error Handling Bad Practices

1. Swallowing exceptions

Bad Example:

Option 1 - Keep the try-catch and handle the error

Option 2 - Proper reactive stream refactoring

1b. Swallowing exceptions - with a reactive stream

Mitigation

2. Over-logging exceptions

Bad Example:

Mitigation

3. Catch generic exceptions

Bad Example

Mitigation

4. (Over-)using checked exceptions

Bad Example

Mitigation

5. Using Exceptions for Control Flow

Bad Example

Mitigation

Conclusion

Some, not so new, thoughts on error handling in Spring and Java

Bad Examples

My Rule

The three steps

1. Log a meaningful message

2. Assess whether you can recover

3. Fail Fast

Summary

Using `for` Loops Instead Of `forEach`

The `for` loop in Kotlin

Basic `forEach` loop in Kotlin

When to use `for` loops

When to use `forEach` loops

Using `lazy` Initialization

Using `new` Keyword

Use `when` Instead Of `if` Or `switch`

Example 1: Using `when` instead of `if-else`

Example 2: Using `when` instead of `switch`

Example 3: Using `when` with ranges

3. Elvis Operator (`?:`)

4. The `!!` Operator (Not-Null Assertion)

6. Safe Casts (`as?` operator)

8. Utilize `let` Function

1. Immutable Variables by Default (`val`)