Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

CAN: returning `Result` instead of `Option`

Aperta
#741 0 commenti 2 reazioni 0 assegnatari Vedi su GitHub

@drewmilkshake ci sta già lavorando.

Dal 28/9/2026.

  • #749 di @drewmilkshake — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
rust
Ambito
embedded-iot

Direzione di ricerca

Start by reviewing the StandardId::new and Frame::new examples in the issue, then inventory the other Option-returning methods in embedded-can and inspect ErrorKind. Done means the relevant constructors return Result values with corresponding errors, while preserving the distinction between invalid IDs and oversized data.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Please correct me if there is a bigger picture that i'm missing…

There seem to be a common habit all through-out embedded-can of returning an Option instead of a Result.
For example:

impl StandardId {
    ...
    /// Tries to create a `StandardId` from a raw 16-bit integer.
    ///
    /// This will return `None` if `raw` is out of range of an 11-bit integer (`> 0x7FF`).
    pub const fn new(raw: u16) -> Option<Self> {
        if raw <= 0x7FF {
            Some(Self(raw))
        } else {
            None
        }
    }

Or:

pub trait Frame: Sized {
    /// Creates a new frame.
    ///
    /// This will return `None` if the data slice is too long.
    fn new(id: impl Into<Id>, data: &[u8]) -> Option<Self>;

In both cases, when:

  • creating a StandardId that is more than 11-bit long, or
  • creating a frame with a data payload bigger than 8 bytes

…None is returned.
However, this is not like, e.g., searching an item in a collection where it's not, thus None is rightfully returned. In both cases user-code is attempting to use illegal values, which is a logic error: therefore, an explicit Error should be returned instead.

So far it kinda works, because each such method only has one reason to fail (and return None): thus the error case is implicit, but remains "deterministic". So this may all sound like a pedantic distinction…

However, consider the following:

/// Create a new Standard Format data frame
pub fn new_standard(raw_id: u16, data: &[u8]) -> Option<Frame> {
    let id = StandardId::new(raw_id)?;
    Frame::new(id, data)?
}

Returning None is no longer an option (pun intended), as we can (pun intended) no longer distinguish between error cases. We're going to have to:

  • use a Result
  • create two custom Errors
  • wrap each None fail-case to return the appropriate one.

It's ugly, verbose, and over-specific in that it forces us to do boilerplate work that really is embedded-can's job, and create custom errors (e.g. IllegalId and DataLengthTooLong(u8)) that really are embedded-can's methods errors…

Therefore i'm suggesting that:

  • all Option-returning methods return a Result instead
  • corresponding errors be added to ErrorKind

Thank you!

Lingua principale
Rust
Stelle
2.7k
Fork
283
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rust-embedded/embedded-hal

Tutte le issue di rust-embedded/embedded-hal

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.