Exception-Free Error Handling in zserio for Safety-Critical Code

[MisterGC]

Motivation

The initial motivation for this proposal is to offer an exception-free error handling mechanism better aligned with functional safety principles. Although MISRA C++:2023 no longer outright bans exceptions, it demands a strong justification for their use—an expectation that certification bodies may continue to scrutinize.

Feedback from zserio users working on safety-critical systems underscores the need for an alternative approach. This proposal is not intended to be definitive but should serve as a starting point for broader discussion.

Drawing from C++23’s std::expected and Rust’s robust error-handling paradigm, the proposed approach aims to balance clarity, maintainability, and the stringent demands of safety standards. While I have not yet fully explored all implications of this design, it highlights important directions worth discussing. I welcome feedback on this approach as well as alternative suggestions.

Context

The zserio C++ codebase (both C++11 and C++17) currently uses exceptions extensively,
which poses challenges for functional safety applications where exceptions are typically prohibited.

Proposed Solution: tl::expected<T,E>

I'd like to propose adopting tl::expected - a C++17 backport of C++23's std::expected. It's essentially C++'s version of Rust's Result<T,E>:

// Instead of:
uint32_t readBits(uint8_t numBits);  // throws on error

// We'd have:
tl::expected<uint32_t, ErrorInfo> tryReadBits(uint8_t numBits) noexcept;

// Usage:
auto result = reader.tryReadBits(8);
if (!result.has_value()) {
    // Handle error explicitly
    return tl::make_unexpected(result.error());
}
uint32_t value = result.value();

Why This Approach?

1. Safety Certification Ready: When compiled with -fno-exceptions, tl::expected becomes deterministic with no hidden control flow
2. Zero Overhead: Stores values/errors in-place (union) - no heap allocation
3. Modern Ergonomics: Supports monadic operations (.map(), .and_then())
4. Future-Proof: Easy migration to std::expected in C++23

Key Challenge: Constructors

Since constructors can't return expected, we'd use factory methods:

class SomeClass {
public:
    // Factory method instead of throwing constructor
    static tl::expected<SomeClass, ErrorInfo> create(const uint8_t* buffer, size_t size) noexcept;
    
private:
    SomeClass(...) noexcept;  // Assumes valid inputs
};

Points for Discussion

1. API Verbosity: Error handling becomes more explicit. Is this acceptable?

   // Monadic style
   auto result = tryReadHeader(reader)
       .and_then([&](auto& h) { return tryReadBody(reader, h); });
   
   // Or macro helpers
   TRY(reader.trySeek(0));
   TRY_ASSIGN(size, reader.tryReadBits(32));

2. Breaking Changes: All APIs would eventually change. How do we minimize user impact?

3. Error Types: Should we use error codes or richer error types?

   enum class ErrorCode : uint32_t {
       BitStreamEof = 0x0101,
       ConstraintViolation = 0x0201,
       // ...
   };
   
   struct ErrorInfo {
       ErrorCode code;
       const char* message;  // static string
       uint32_t context;
   };

What I'd Like to Know

• Are there users who absolutely need exceptions?
• What's your experience with std::expected or similar types?
• Any concerns about the factory method pattern for object construction?
• Should we have a compatibility transition phase for easier migration?

Looking forward to your thoughts! This is a significant change, but I believe it's necessary for zserio to meet modern safety standards while maintaining good ergonomics.

References

• tl::expected documentation
• std::expected documentation
• P0323R12: std::expected