Serde and error handling

Is there any way to just tell serde to ignore errors when deserializing? E.g. for something like

/// The main data structure for deserializing with serde.
struct SerdeDataSourceHelper {
    title: Option<String>,
    base_url: Option<String>, // ???
    projects: Option<BTreeMap<String, BTreeMap<Url, BTreeMap<String, SerdeForkOptions>>>>,
    repo_list_srcs: Option<Vec<SerdeRepoList>>,
    project: Option<BTreeMap<String, SerdeProjectOptions>>,

/// The options for a given fork.
struct SerdeForkOptions {
    active: bool,
    federate: bool,

/// A repo list.
struct SerdeRepoList {
    url: Url,
    active: bool,
    allow_negative_entries: bool,

/// The options for a given project (all forks).
struct SerdeProjectOptions {
    active: bool,

is there any way to tell serde to just... ignore stuff that doesn't match the expectation? So if someone shoved a list where a deeper level of the BTreeMap was expected it'd just ignore that list entirely, etc etc?

Maybe something with using an untagged wrapper enum...? Surely there's a better way of doing this? .-.

What about creating your own MaybeInvalid<T> wrapper type?

enum MaybeInvalid<T> {

impl<'de, T> Deserialize<'de> for MaybeInvalid<T>
    T: Deserialize<'de>,
    fn deserialize<D: Deserializer<'de>>(de: D) -> Result<Self, D::Error> {
        match T::deserialize(de) {
            Ok(valid) => Ok(MaybeInvalid::Valid(valid)),
            Err(_) => Ok(MaybeInvalid::Invalid),



So instead of Option<T> we'd use... hm...

Say, why's there no Result<T, ()> serialization, equivalent to Option<T> but discards deserialization errors? Seems like it could be useful for error management.

Well Option<T> means either you have a T or it's not present, which is very different from "I have a T or something which is invalid".

Using Result<T, ()> for this would be incompatible with serde's existing blanket impl. Defining a meaningful, specific wrapper type seems better in pretty much every way.


Well what do you call "I have a T or I don't care what I have"? That's basically the same as Option...

Not at all. Option indicates the absence of something whereas your "I don't care what I have" can mean the item is not present or not valid.


Not being present can be a form of not being valid, tho. And vice-versa.

Rust and crates are always failing error handling...

You are, as always, free to send pull requests to projects.


This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.