Hello everyone! I have a quick question for librar...

# serialization

[sandwwraith]

Hello everyone! I have a quick question for library users: does anyone rely on the fact that Json.decodeFromString can throw arbitrary IllegalArgumentException? For example, from init { require(x > 0) } blocks in serializable data classes. I'm asking this because there are a few requests to change that (https://github.com/Kotlin/kotlinx.serialization/issues/3111, https://github.com/Kotlin/kotlinx.serialization/issues/2165) that seem reasonable to me. But implementing them would mean that you cannot longer do catch(e: IllegalArgumentException) or catch(e: NumberFormatException), which is kinda incompatible behavior change. So far I'm thinking that augmenting exceptions this way will bring more good than harm; does anyone have arguments against?

[hfhbd]

The docs already mentions you should call IllegalArgumentException, so I am okay with it, as long as the original exception is passed as the cause of the SerializationException.

I do use the require pattern in the constructor very often, but I have a IllegalArgumentException catch clause when decoding JSON (or other formats).

[sandwwraith]

Well, if you have both catch SerializationException and catch IllegalArgumentException now everything will go to the first one

[sandwwraith]

Or are you saying you always used only catch IllegalArgumentException because it has wider scope?

[hfhbd]

Yes to the second one: I (!) only use catch IllegalArgumentException

[Oliver.O]

Just for clarity:

But implementing them would mean that you cannot longer do catch(e: IllegalArgumentException)

You can, because SerializationException is a subclass of IllegalArgumentException, right?

The breaking change in this case would affect users which are now catching both, right?

or catch(e: NumberFormatException),

So this would be the real breaking change, right?

If my understanding is correct, I'd say the current way of differentiating between the above exceptions does not make a lot of sense, so breaking it is the reasonable way forward.

[hfhbd]

Yes, SerializationException is a subclass of IllegalArgumentException

[sandwwraith]

or catch(e: NumberFormatException),

So this would be the real breaking change, right?

Yes, this clause won't be triggered anymore. catch(e: IllegalArgumentException) also won't be executed if you have more specific catch (e: SerializationException)

[pdvrieze]

I have found that wrapping underlying exceptions allows adding vital context that helps understanding what went wrong (and location in the file/stream it happened).

[Filipp Zhinkin]

Continuing on that matter: do you catch specific SerializationException sub classes? MissingFieldException is one popular exception to catch. But is there a reason to catch other specific SerializationException s?

github.com/Kotlin/kotlinx.serialization/issues/3262 raises a fair question, but for serialization exceptions there might be more harm than good.

[CLOVIS]

For example, from init { require(x > 0) } blocks in serializable data classes.

I absolute write code like that. However I never catch the related exception in business-critical code, only in logger/Ktor StatusPage stuff, which won't be problematic if the subclass slightly changes