Does Kotlin have multi-catch?

21

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

8 Likes
22

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
23

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

6 Likes
24

And this is the final wish:

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

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.

2 Likes
26

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

27

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!

28

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

29

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
30

Read the article fully…

31

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
32

lol read the article 4 messages above :laughing:

33

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:

34

3 years has passed .

2 Likes
35

On Jun 15 '20, @lamba92 referred to this article which educates us about how using exceptions (checked or not) as a way to communicate the result of an invocation is a bad idea.

Kotlin and Exceptions
by Roman Elizarov,
Project Lead for the Kotlin Programming Language @ JetBrains

It is really worth internalizing that advice in your own API design.

Meanwhile, when having to use an API that does convey the result of an invocation via Exceptions, catching Exception and subjecting it a when is a reasonable workaround for those rare situations where there is a better strategy than throwing it up the call-chain.

2 Likes
36

Is there any news about this topic?

Thanks

1 Like
37

Bumping for visibility

38

Bumping for extra visibility

1 Like
39

One if the reasons it can be good to withhold a feature is to make room for other better features. Kinda like how people like ternary until they realize how great if-expressions are.

Now we’re closer to union types than in the past but there’s likely a wait. There might be an argument to add multi-catch in a conservative manner so we don’t have to wait–but I assume potential future of union types would at least be considered in the design.

It’s good to show interest but I’m not sure where this one fits in priority with other features. I assume this one would be a freebie with union types

1 Like