Skip to content

[RELAY-TERM-EXTRA-02] ErrInvalidFrame is thrown as a C++ exception instead of returned as std::error_code, deviating from §18.2 #48

Description

@SoundMatt

Location, confirmed at current HEAD. include/lin/lin.hpp:83 (class ErrInvalidFrame : public std::runtime_error), used throughout src/lin.cpp (e.g. lines 35, 59, 61, 63, 65, 112, 115) and
declared as the throw behavior on ValidateFrame/from_message in lin.hpp:151,160; also
src/relay.cpp:60 throws a bare std::invalid_argument from parse_protocol.

Finding. The audit's §3.4 error-sentinel-model matrix notes that most RELAY-conformant C++ ports
follow the std::error_code/error_category pattern the spec's §5.2/§18.2 error-wrapping model is
built around, "except where protocol errors are thrown as exceptions instead (cpp-CAN
ErrInvalidFrame, cpp-LIN ErrInvalidFrame/dead ErrNoResponse) — a real §18.2 deviation, not
cosmetic." Re-checked against current HEAD: this repo's ErrInvalidFrame is not a std::error_code
value at all — it's a distinct exception type derived from std::runtime_error, thrown from every
frame-validation and message-conversion call site rather than returned. A caller written against the
spec's std::error_code convention (as sibling protocols use) has no way to catch this condition
without knowing to catch (const lin::ErrInvalidFrame&) specifically, which is a materially different
calling convention than the rest of the ecosystem. The companion ErrNoResponse dead-code angle on
this same exception-vs-sentinel mismatch is already tracked separately as issue #34
([cpp-LIN-03]) — this issue is scoped to the broader exception-vs-std::error_code architecture
choice for ErrInvalidFrame specifically, which #34 does not cover.

Recommendation. Convert ErrInvalidFrame (and the std::invalid_argument thrown from
parse_protocol) to the std::error_code/error_category pattern used elsewhere in the C++ port
family, returning it rather than throwing, so callers can handle it uniformly with the rest of the
RELAY C++ ecosystem per §18.2's error-wrapping model.


Filed from the 2026-07-29 ecosystem audit register; independently re-verified against current HEAD before filing.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions