Three reasons. Code size: to support exceptions the compiler emits unwind tables describing how to destroy every live object along every path an exception could propagate, which can add tens of kilobytes, significant on a part with a few hundred KB of flash. Non-deterministic timing: throwing walks the stack running destructors until it finds a handler, and how long that takes depends on call depth and live objects, which violates the bounded worst-case execution time hard-real-time code needs. Nowhere to recover: on bare metal there's often no meaningful layer to handle something like an I2C NACK, and an uncaught exception calls std::terminate, which typically resets or hangs the device. So firmware builds with -fno-exceptions and reports errors via status-code return values or a Result/expected<T,E> type that the type system forces you to check. The deeper point is that exceptions optimize for the rare error path at the cost of size and determinism, a trade bare metal usually can't make.
C++ for Embedded · Interview question
Why are C++ exceptions usually disabled on microcontrollers?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
What to Avoid on MCUs
The three C++ features that cost more than they're worth on a microcontroller (exceptions, RTTI, and dynamic allocation): why they hurt, and the deterministic patterns to use instead.