[mrkline]

> you just need to start from this point if you know your environment is really constrained and exceptions are too much of a cost - which is usually not the case in modern embedded ARM systems.

ARM systems really run the gamut these days - while many are quite powerful (see: my phone), many also fall on the more traditional microcontroller side, with very little in terms of flash and RAM. In case it wasn't clear, this article focused on the latter.

[pjmlp]

An ARM Cortex-M4 is already powerful enough to run a Java runtime.

http://www.microej.com/products/device-software-development/...

[mrkline]

Great! But when you have hard timing requirements measured in microseconds, you generally need some fine-grained control over the instructions the CPU ends up running. All the knobs and levers C and C++ offer you are quite useful here.

[pjmlp]

True, but those embedded Java runtimes also have such kind of knobs and levers, they just look different from what C and C++ devs are used to.

[leovonl]

Indeed, in the later case, exceptions are really an unnecessary cost.

In fact, another argument which could be made against the use of exceptions is that the abstraction per se is not a really good mechanism for abstracting error handling. Explicitly handling errors - including try!() à la Rust and/or monadic composition of functions - usually leads to a better error coverage, as safety is enforced by the type system itself.

[mrkline]

I would _love_ to write our firmware in Rust, but that's a much bigger sell than moving from C to C++.