Consider adding error message field to AttributeError

[Veetaha]

💡 Feature description

Consider adding a message field to AttributeError.
It is useful for debug purposes to know what exactly might have failed when parsing the attributes instead of
information-less AttributeError::InvalidType and AttributeError::InvalidFormat.
It might look like this:

pub enum AttributeError {
-    InvalidFormat,
+    InvalidFormat { message: String },
-    InvalidType,
+    InvalidType { message: String },
    MissingField {
        name: String,
    },
}

💻 Basic example

In my case I try to follow single-table dynamodb design.

So I created a db::Id struct which represents an string of format kind#uuid:

The code is this:

struct Id<K>(Uuid, PhantomData<*mut K>);

// ToString and FromStr implementation for Id<K> is skipped...

impl<K: HasKindTag> dynomite::Attribute for Id<K> {
    fn into_attr(self: Self) -> dynamodb::AttributeValue {
        self.to_string().into_attr()
    }
    fn from_attr(value: dynamodb::AttributeValue) -> Result<Self, dynomite::AttributeError> {
        value
            .s
             // we lose the info about the original type in the error message here
            .ok_or_else(|| dynomite::AttributeError::InvalidType)?
            .parse()
            // Unfortunatelly we lose error message from parsing here too...
            .map_err(|_err| dynomite::AttributeError::InvalidFormat)
    }
}

[softprops]

This sounds doable. Thanks for the design feedback

[softprops]

For context on the current types, both encode information in their type but have room for improvement in messaging details

dynomite::AttributeError::InvalidType

• provides information to users that the type of a value is invalid given the context
• an improvement could be what type is given

dynomite::AttributeError::InvalidFormat

• for data types that require coercion, this provides information that the underlying data is in an invalid format
• improvement here could be to surface the values contents

Since information is provided let's not call call this "informationless". Let's call the improvement "information rich"