Skip to content

External API FromStrs could have api::external::Error as their error type #8238

@FelixMcFelix

Description

@FelixMcFelix

impl FromStr for L4PortRange {
type Err = String;
fn from_str(range: &str) -> Result<Self, Self::Err> {
const INVALID_PORT_NUMBER_MSG: &str = "invalid port number";
match range.split_once('-') {
None => {
let port = range
.parse::<NonZeroU16>()
.map_err(|_| INVALID_PORT_NUMBER_MSG.to_string())?
.into();
Ok(L4PortRange { first: port, last: port })
}
Some((left, right)) => {
let first = left
.parse::<NonZeroU16>()
.map_err(|_| INVALID_PORT_NUMBER_MSG.to_string())?
.into();
let last = right
.parse::<NonZeroU16>()
.map_err(|_| INVALID_PORT_NUMBER_MSG.to_string())?
.into();
Ok(L4PortRange { first, last })
}
}
}
}

The FromStr impls in our external API mostly return Strings with some anyhow::Errors. We could converge on omicron_common::api::external::Error::InvalidValue instead, to give a little more context where more complex strings are handled.

#8194 converts the types used in firewall rules to this errorkind, but we could maybe go further here. Most of the types here have straightforward parsing, but types like Digest might benefit since they apply a similar tag:value pattern.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions