DecodingFailure contains no useful information

When a DecodingFailure happens, I expect it to contain some information helpful for debugging, i.e., which part of the json string cannot be decoded. But its message is just some type name such as String, Long, etc and its history is always an empty List. Or how can I get more information from a DecodingFailure ?

[travisbrown]

@psttf This is something we’ve thought a lot about, and while I definitely agree that the current approach isn’t perfect, the trade-offs are something we’ve considered. Not saying it could never change, but I think it’s unlikely.

In general my recommendation would be to try to use alternative approaches to error handling that don’t require you to deal with undifferentiated exceptions in IO at some high level, which is when stack traces would be valuable.

I know that’s not always practical, though, and if you do decide to wrap the failure in order to get a stack trace, one additional benefit of the fact that DecodingFailure extends Exception is that you can use the Java Throwable hierarchy’s Throwable cause constructor, instead of having to use a custom Exception class or make decisions about how to represent the DecodingFailure as a message string.

[psttf]

@travisbrown Thank you for the explanation! It turns out that I was confused by the fact that DecodingFailure extends Exception. This makes it possible to apply IO.fromEither and the like to Decoder.Result, but it results in having untraceable errors without stack traces in error logs. Maybe it is better to not extend Exception at all? Then it will always be necessary to wrap DecodingFailure in an Exception before applying IO.fromEither and automatically get traceable errors? And for convenience there may be a syntax method to do such wrapping easily in a Decoder.Result.