Use case for RuntimeException from package Kotlin

Question

I was writing some code and was going to throw a RuntimeException as a default for something, when I noticed that there are two options for RuntimeException - one from java.lang and one from kotlin:

Inside the kotlin version of this, there's an entire list of other methods which work the same way :

So, from my understanding of this, the one from package kotlin is simply an alias for the java equivalent (correct me if I'm wrong) which leads me to the question :

what is the point of having this alias file and when should you use it over the "standard" java equivalent ? Does this simply save a few imports ?

I think there's no real use case in this exception, it's only a parent for some Kotlin-specific exceptions, like `UninitializedPropertyAccessException` — Vitalii Malyi, Oct 01 '19 at 14:06
I think alias were created in case of provide some fluent API like Kotlin DSL in nearer future. It's like following abstract factory pattern to provide APIs/SDK with minimal or none change logs if we got to higher versions of library. — Jeel Vankhede, Oct 01 '19 at 14:12

score 7 · Accepted Answer · answered Oct 01 '19 at 14:11

7

When using the JDK, these map to JDK classes. When using Kotlin for Javascript, they would map to a specific implementation in the Kotlin Javascript library. Documentation about actual and expect here.

To answer your question, if there's a chance of you porting your code to also work on another platform, always use the kotlin. variant. Otherwise, it doesn't matter.

answered Oct 01 '19 at 14:11

Tenfour04

83,111
11
94
154

learn something new every day, thanks for your answer, this was pretty cool – a_local_nobody Oct 01 '19 at 15:48

score 1 · Answer 2 · answered Oct 01 '19 at 16:10

In my opinion typealias is strong feature provided by Kotlin language.

Why? Because it gives ability to extend code to multiple domains like extension to provide interoperability between any other languages and Kotlin.

It also becomes helpful when providing APIs or SDK with semantic versioning without worrying much about changes affecting on lower versions of APIs.

One good example would be Collections derived from Java to Kotlin language with some additional & powerful methods as typealias (Literally it saves lot of development time and efforts).

Another good example would be multiplatform programming support by Kotlin language that helps you create APIs with actual and expect keywords implementation.

So long story short, I prefer using RuntimeException from Kotlin package to extend support amongst variety of Kotlin versions (You can see newly added classes starting from version 1.3, but doesn't affect existing API).

Use case for RuntimeException from package Kotlin

2 Answers2

Linked