Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exceptions thrown should be SerializationException #228

Open
florianmutter opened this issue Jul 18, 2024 · 3 comments
Open

Exceptions thrown should be SerializationException #228

florianmutter opened this issue Jul 18, 2024 · 3 comments

Comments

@florianmutter
Copy link

To make it easier to handle issues when serialization or de-serialization xmlutil should throw exceptions that inherits from kotlinx.serialization.SerializationException

@pdvrieze
Copy link
Owner

I can have a look at that for exceptions in the serializer code/module itself (I believe those are already inheriting SerializationException), but parsing is an independent module that throws its own exceptions. There can also be exceptions thrown by the (de)serialized classes.
A separate issue is compatibility with existing code, and adding a superclass would be a potentially breaking change.

@sschuberth
Copy link
Contributor

Would implementing this solve the issue of exceptions not listing the affected field? I'm currently getting something like

Exception in thread "main" java.lang.NumberFormatException: For input string: ""
	at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
	at java.base/java.lang.Integer.parseInt(Integer.java:672)
	at java.base/java.lang.Integer.parseInt(Integer.java:778)
	at nl.adaptivity.xmlutil.serialization.XmlDecoderBase$DecodeCommons.decodeInt(XMLDecoder.kt:112)
	at kotlinx.serialization.internal.IntSerializer.deserialize(Primitives.kt:125)
	at kotlinx.serialization.internal.IntSerializer.deserialize(Primitives.kt:121)
	at nl.adaptivity.xmlutil.serialization.XmlDecoderBase$TagDecoderBase.decodeNullableSerializableElement(XMLDecoder.kt:906)

with no indication which Int-field cannot be deserialized as its input contains an empty string.

@sschuberth
Copy link
Contributor

Would implementing this solve the issue of exceptions not listing the affected field?

Nevermind, I guess I'm looking for #197.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants