Reporting location information in errors

[charleskorn]

Continuing the discussion from #309:

@charleskorn:

Are there any plans to better support reporting location information when errors occur? For example, if I try to deserialise 'abc123' as a boolean, it would be great to be able to say what line and column in the stream 'abc123' is on. I've implemented my own solution for the time being but it would be nice if this information was used by the core library and exposed to custom serializers in a consistent way.

@sandwwraith:

I personally think this is highly format-dependent. E.g. binary formats can have only byte offset in a stream, string formats can either have both line and column or only char offset (json can be treated as one big line, and usually unformatted json from rest apis doesn't contain indentation or line breaks). Exceptions also are very likely to be format-specific. Although, it may be possible to commonize an error location (as Location you have), I'm not sure that it will be sufficient for all formats. If you have ideas on how it could be correctly designed, feel free to open a separate issue.

I'm just thinking out loud here, but could there be some very generic Location interface that Decoders can expose (from something like a currentLocation property), and which the engine can then use in exceptions? Then each format could implement something that makes sense - binary formats can give byte offsets and text formats can give line and column information, for example.

These two options could even be included in the runtime itself and formats can then either extend from them if necessary or just add their own.

I haven't spent a lot of time thinking this through, so I'm open to other ideas and feedback :)

[edenman]

I would love if this were added (and if it were made available on the Decoder for custom serializers to use).

FWIW Moshi calls this a "path" and I like the terminology: https://github.com/square/moshi#fails-gracefully

[charleskorn]

I ended up implementing this in Kaml - exceptions have location (line and column) and path (eg. users[2].name) information, and this is also accessible to custom serializers. The implementation isn't perfect, but it could be useful inspiration for what broader support in kotlinx.serialization could look like.

[sandwwraith]

I think #1841 delivers most of the points here, and we likely won't implement a format-independent solution. So I'll close this.