[Pitch] Improve `EncodingError` and `DecodingError`'s printed descriptions

Evolution Pitches
,
1

I’ve got a draft PR of a pitch to improve the errors that are printed when using Codable: Add SE proposal for Codable error printing by ZevEisenberg · Pull Request #2843 · swiftlang/swift-evolution · GitHub

I’d love to hear initial thoughts, as well as get clarity on the one major open question:

## Implications on adoption

[Unsure what to add here. I see stuff in [SE-0445](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0445-string-index-printing.md#implications-on-adoption), but I'm not sure how much of that applies here. I don't know if I need to be doing the `@backDeployed` things that proposal mentions, and when I look at the code from the PR, I see `@_alwaysEmitIntoClient // FIXME: Use @backDeployed`.]
6 Likes
2

In all the projects I work on I add extensions to convert [any CodingKey] into either JSONPath, XPath or KVO key path depending on the decoding format.

I appreciate the utility in debugDescription including this path within the string but I may still reach for DecodingError.Context.codingPath to extract it to a single property.

3

By all means! I’m hoping to raise the floor on how approachable these errors are out of the box. There’s definitely more purpose-built things you can do, as well as utilities that provide more debugging context. Hopefully whatever follows Codable will do more like this from the start.

1 Like
4

It looks like the pitch is about taking us from:

keyNotFound(CodingKeys(stringValue: "population", intValue: nil), Swift.DecodingError.Context(codingPath: [_CodingKey(stringValue: "Index 0", intValue: 0), CodingKeys(stringValue: "home", intValue: nil), CodingKeys(stringValue: "country", intValue: nil)], debugDescription: "No value associated with key CodingKeys(stringValue: \"population\", intValue: nil) (\"population\").", underlyingError: nil))

…to:

Key 'population' not found in keyed decoding container.
Debug description: No value associated with key CodingKeys(stringValue: "population", intValue: nil) ("population").
Path: [0]/home/country

Thank you! Showing the coding path as a path makes it much easier to read and work with. I appreciate your work.

5 Likes
5

I'm all for it! My extensions usually produce a slightly terser debug description so I'm throwing it out there but I don't mind your format!

I don't remember exactly but its something like that:

[0]/home/country: expected 'population' key

With underlying errors if applicable:

body[2]/text/weight: expected value of type 'FontWeight' but got "boldd"
  ↳ unknown font weight "boldd", valid values are "ultraLight", "light", "regular", "semibold", "bold", "black"
6

I’m not opposed to massaging the formatting! I opted for something that was more verbose to try to be friendlier to newcomers, who seem to be the most confused by the current errors, and I’m also trying to do the best I can with the current errors that are generated by JSONDecoder and friends. But we can also iterate on changes between stdlib (home of these error types) and Foundation (home of the en/de-coders) until we get something we’re happy with. Turns out, it can be complicated to test and land a change that affects both!

2 Likes