Does Kotlin have multi-catch?

Well, who knew that reading the documentation would be of any value :wink:

when matches its argument against all branches sequentially until some branch condition is satisfied

Of course in my case it didn’t work, since Exception was listed first.

1 Like

While we wait for the multicatch support I’ve created this extension that may help someone:

fun <R> Throwable.multicatch(vararg classes: KClass<*>, block: () -> R): R {
     if (classes.any { this::class.isSubclassOf(it) }) {
         return block()
     } else throw this
}

Usage:

try {
    ...
} catch (e: Exception) {
    e.multicatch(SomeException::class, OtherException::class) {
        // Shared catch execution
    }
}
9 Likes

Thanks carlesic! That is a pretty reasonable work around! Wish I thought of it!

It’s a pity it requires kotlin.reflect

2 Likes

You can avoid reflect and adding new method by using whenclause, it is not much longer:

try {
    ...
} catch (e: Exception) {
    when(e){
         is SomeException, is OtherException -> {...}
         else -> {}
    }
}
8 Likes

To mimic multi-catch the else branch should rethrow the exception.

try {
    ...
} catch (e: Exception) {
    when(e) {
         is SomeException, is OtherException -> {...}
         else -> throw e
    }
}
4 Likes

Is there an issue that we can vote for to get this in?

8 Likes

Yes - https://youtrack.jetbrains.com/issue/KT-7128

It seems very odd that after 4 years this issue is still awaiting prioritisation.

I get that exceptions are not ‘cool’ from a functional perspective, but Kotlin is a General Purpose language, and allow succinct code in the main programming styles.

7 Likes

Maybe they are actively considering union types, in which case multi-catch would follow for free.

6 Likes

And this is the final wish:

try {
    // code
} catchWhen(ex:Exception) {
        is SomeException,
        is AnotherException -> {
            // handle
        }
        else -> throw ex
}
5 Likes

I also encountered situation for multi catch today and landed here.
Sadly, I see lot of people already reported this, and no action taken till now.

3 Likes

@yole as it’s been awhile since last reply, I am wondered if there any foreseen time-line for implementing this feature?

As probably already stated in this thread, not supporting checked exceptions and, nevertheless, multi-catch is a design choice. To better understand the problems of checked exceptions and whatever construct derivates from it, I recommend this post from @elizarov. His blog is a great source for understanding many design choices of Kotlin!

Not having multi-catch has nothing to do with not having checked exceptions. Both approaches are orthogonal to each other.

I think you meant that multi catch and checked exceptions have nothing to do with each other :wink:
That said, if you follow the coding guidelines provided in the link you don’t have much use for multi catch. Still it would be a nice feature to have.

1 Like

Read the article fully…

Posting this comment for visibility.

It’s astonishing that after 6 years and over 300 likes on https://youtrack.jetbrains.com/issue/KT-7128 this feature still hasn’t been added.

1 Like

lol read the article 4 messages above :laughing:

Just created my own implementation for that…

This is how it looks like:

        unsafe {
            danger {
                // place some danger code that probably throws an exception.. (placed in try-Block)
            }
        
            except(ConnectException::class, SocketException::class) {
                // catch code for either ConnectException or SocketException
            }
        
            except(NullPointerException::class) {
                // multiple catch blocks possible
            }
        }

The implementation of the Unsafe-Class is on Github:

3 years has passed .

2 Likes