Kotlinx.serialization: Unable to catch MissingFieldException

[carbotaniuman]

What is your use-case and why do you need this feature?

I'd like to programmatically catch MissingFieldExceptions without having to resort to reading the stacktrace in order to check.

Describe the solution you'd like

Make MissingFieldException public.

[qwwdfsad]

Could you please elaborate on what exactly are you trying to achieve? E.g. provide a snippet of code and/or a use-case.
Then we could understand why it is important to differentiate MFE from other serialization exceptions

[carbotaniuman]

For me it's just to fulfill an API contract and return a better error, so if you don't want to commit to this in the public API my hack works fine for me.

[qwwdfsad]

if you don't want to commit to this in the public API

Well, it's not really about us wanting it or not, but about the rationale behind the decision. In general, we're trying to keep public API as small as possible, but still concise and pragmatic. So before making it public, we should know why it can be useful.

For me it's just to fulfill an API contract and return a better error

Could you please elaborate on why you can't catch plain SerializationException there? Or how MissingFieldException handling is different from SerializationException?

[bukajsytlos]

I second this and also not having the field name as an attribute of exception.
I my case, when I am parsing json request and there is a missing field and I want to provide custom error response message I would have to parse message to get info I want, instead of catching specific exception which would have this field attribute and I can do whatever I want with it.

[bukajsytlos]

@qwwdfsad ping

[qwwdfsad]

I second this and also not having the field name as an attribute of exception.

For example in 1.1.0 it will be not the name, but names: https://github.com/Kotlin/kotlinx.serialization/blob/dev/core/commonMain/src/kotlinx/serialization/SerializationException.kt#L70 And it's nice for us to have an ability to freely change this API without preserving backwards compatibility.

Could you please elaborate on what's wrong with the default error message and how can we improve it?
Or, additionally, why you have to differentiate e.g. invalid data (e.g. expected string, but have int) from missing field exception?

[bukajsytlos]

for example internationalisation

[bukajsytlos]

well as in my example, when using serialization for http requests, I want to tell client why is his input bad, what's wrong with it, and which field is responsible

[jeffk-kiva]

Because we can only catch SerializationException, it is difficult to programmatically know if it's an issue due to improper JSON formatting, missing fields, or extraneous fields. We could parse the string and use that to determine which issue we're facing, but that is obviously a lot less safe than relying on a type.

Uses for being able to differentiate based on type instead of just letting the error message through include: different logging requirements depending on the organization (e.g. the error message may contain sensitive information), custom error codes for clients, custom error messages for clients, error reporting in an event-based architecture, routing to an appropriate error-correction handler, etc. There are many possibilities.