What an exciting thread! I'd like to put in a request to please consider error handling. A common source of grief for beginners is difficulty in reading the error messages thrown by Codable. Some information is missing, and it's formatted such that you really have to do some digging to understand it. It is especially unapproachable to beginners.
Here are some things I'd like to see in an improved tool. I'm mentioning them now in case it's useful to think about what kind of file/line metadata might be useful to carry along with the macro-annotated types and fields described above:
- A clear, concise path from the root of the source data to the field that is causing a problem.
- If possible, some context from the source data. Give me bytes, lines, characters, anything!
- A more straightforward explanation of why the data that was encountered is not satisfactory for the decoding specified.
- A reference to the line of code that defined the field that had a problem.
Here's an example of what Codable does now:
valueNotFound(Swift.String, Swift.DecodingError.Context(codingPath: [_JSONKey(stringValue: "Index 0", intValue: 0), CodingKeys(stringValue: "address", intValue: nil), CodingKeys(stringValue: "city", intValue: nil), CodingKeys(stringValue: "birds", intValue: nil), _JSONKey(stringValue: "Index 1", intValue: 1), CodingKeys(stringValue: "name", intValue: nil)], debugDescription: "Expected String value but found null instead.", underlyingError: nil))
Quick, find what's wrong!
A while back, I wrote an experimental micro library, UsefulDecode, which attempted to format the error messages from Codable. Here is what UsefulDecode produces for the same error message:
Value not found: expected 'name' (String) at [0]/address/city/birds/[1]/name, got:
{
"feathers" : "some",
"name" : null
}
Per my last bullet point above, something like this in an error message would be useful:
Could not decode value "abc123" which was specified as 'Date' with format 'iso8601' at MyModel.swift:43
I hope the example illustrates why I think it's important to be thinking about this, and I hope it sparks some good conversations about what might be needed to produce such diagnostics.