Why does Sonarqube mark try as a critical issue?

Question

I'm currently facing an issue with some SonarQube's analysis being performed over some Kotlin code I wrote.

I'm trying to implement a method that connects to the database and returns accordingly to the query's result. I'm not sure how related this can be, but I added the following maven dependencies to my project:

• Quarkus
• Arrow
• Ktorm

The code is the following:

@ApplicationScoped
class Repository(private val database: Database) {
    override fun get(name: String): Either<Error, Brand> =
        try {
            database.brands.find { it.name eq name }.rightIfNotNull {
                MissingBrandError("Missing brand")
            }
        } catch (e: Exception) {
            Either.Left(DatabaseError(e.message))
        }
}

class Error(val message: String)
class MissingUserError(val message: String) : Error(message)
class DatabaseError(val message: String? = null) : Error(message ?: "Some database error")

NOTE: Database object is of type org.ktorm.database.Database and brands is of type org.ktorm.entity.EntitySequence

The code is working and I also wrote unit tests for it that pass and give enough coverage (accordingly to the code coverage analysis tool), but at some point in my pipeline SonarQube marks the try as a critical issue with the following message:

Possible null pointer dereference in (...)Repository(String) due to return value of called method

I checked it online and I could find some related questions, but none of the provided answers worked for me. Amongst the many attempts these are the ones I can remember I tried without any success:

1. Not inlining any code (pretty much using Java style code)
2. Extracting the query result to a variable
3. Check with if/else statements for nullability instead (both with inlined try and without)

I'd also like to highlight that all I can see on Sonar is the generated report and CLI for the running build. I don't have access to any of its configuration or intended to change them (unless of course it comes down to that). The line I mentioned seems to be the only one affected by this problem according to Sonar's report, that's why this is the solo class I provided.

I hope I provided enough info and that any of you can help me with this. Thanks in advance.