Deserialization errors are near-useless for complicated objects

[vriesk]

When deserializing a complex object with multiple levels of nested sub-structures, the errors encountered upon deserialization are near useless, because they completely lack context.

The internal ErrorImpl can tell me what kind of issue was encountered, but not where. When trying to debug a large structure, this requires spending a lot of time staring on it and trying to figure out what could have possibly got mismatched.

Would there be some hope for providing error context during deserialization? Serialization is much less of a concern here, because it is rather unlikely to be triggered by wrong external input.

Note: it's not just serde_dynamo that suffers from this, and maybe this must be addressed on serde level, unsure here.

[parrottq]

I've improved the error handling in this PR: #105.

Deserialization failures include the AttributeValue that failed to deserialize and the path to that value as context inside the Error type.

Example from the wrong_types unit test:

#[derive(Debug, Deserialize)]
struct User {
    id: String,
    name: String,
    age: u8,
}

let items: Vec<HashMap<String, AttributeValue>> = vec![
    HashMap::from([
        (String::from("id"), to_attribute_value("two").unwrap()),
        (String::from("name"), to_attribute_value("John").unwrap()),
        (
            String::from("age"),
            to_attribute_value("not a number").unwrap(), // <- Should be a number
        ),
    ]),
];

let err = from_items::<Items, User>(items.into()).unwrap_err();
assert_eq!(
    String::from("Expected num at '[0].age'. Value: S(\"not a number\")"),
    // Previously: "Expected num"
    err.to_string()
);