A conversation about errors…

We had an interesting discussion on our Patreon Slack Group about errors last week. Elecia was thinking about error handling in a small embedded system with safety critical functionality. She had decided upon functions returning errors and having a unified my_errno.h. In general, the calling functions should handle what errors they can and return what they can’t according to:

1. Retry where appropriate, for a limited time.
2. Log the error (allowed on her system).
3. Bubble the error up to higher level code which can either

She and Phillip Johnston (EmbeddedArtistry) talked about how important it is to consider what action a system can take when dealing with errors (“What exactly am I going to do if there’s an error?”). Elecia’s system has limited recovery beyond stopping (ideally gracefully).

Simon mentioned asserts which are incredibly useful, especially for debugging. For embedded systems, asserts go to interrupts which usually log a bit of data to memory and then reboot (and that logged data gets sent to somewhere). For Elecia’s system, she doesn’t want reboots and returning from assertions is sometimes not trivial to rollback correctly: they are supposed to be used for impossible bugs.?

Then the discussion moved whether one or multiple return paths from functions were preferable. MISRA commands that we shall all return from one location. Is that what you do?? Elecia plans to bow to the forces of a single return to rule them all. Then they agreed that returning structures would be interesting but not worth it.

Then there is the dreaded close file or release mutex problem: You get an error after you’ve opened something. One popular C option is a goto:

Using goto for error clean up is probably the only place folks agreed goto should be used.?

One option is nested if-conditions to clear the side effects.

This can get cumbersome. Nathan Jones suggested a switch statement with intentional fall through.

(Elecia hated it, taking a hard stance that switch statements are a path to ruin but that was a different rant.)

Nathan, getting ready for his EOC25 talk on error handling, already had some excellent resources on hand:

• "Beyond errno in C" (David Svoboda): Great introduction to the topic
• "The different ways to handle errors in C" (Ethan McCue): Exhaustive list with minimal judgement on the best thing to do
• "Safe structures for error codes" (Phillip Koopman): Good explanations on reasons to choose one way or another
• "Error codes or Exceptions? Why is Reliable Software so Hard?" (Damien Katz): A C++ option
• "Code Complete" by Steve McConnell also has a lot of great exception/error handling advice.

Elecia looks forward to his talk. Any good conversations around your watercooler?

Memfault is a leading embedded device observability platform that empowers teams to build better IoT products, faster. Its off-the-shelf solution is specifically designed for bandwidth-constrained devices, offering device performance and product analytics, debugging, and over-the-air capabilities. Trusted by leading brands such as Bose, Lyft, Logitech, Panasonic, and Augury, Memfault improves the reliability of devices across consumer electronics and mission-critical industries such as access control, point of sale, energy, and healthcare. To learn more, visit?memfault.com.

Links of the week:

• This two part internal NSA lecture by Admiral (then Captain) Grace Hopper?(part II here) was just recently released. Admiral Hopper discussed?"some of the potential future challenges of protecting information. She also provided valuable insight on leadership and her experiences breaking barriers in the fields of computer science and mathematics."
• Get comprehensive coredumps with PlatformIO and the Arduino framework. It's nice to see more debugging and analysis capabilities make their way down to hobbyist friendly tools.
• If you've ever wanted an exhaustive list of every UUID, well?https://everyuuid.com/?has you covered. This blog post describes how the site is made, which is acutally a tricky problem in web development.

Nordic Semiconductor has been the driving force for Bluetooth Low Energy MCUs and wireless SoCs since the early 2010s, and they offer solutions for low-power Wi-Fi and global Cellular IoT as well. If you plan on developing robust and battery-operated applications,?check out?their hardware, software, tools, and services.

On?academy.nordicsemi.com,?you’ll find Bluetooth, Wi-Fi, and cellular IoT courses, and the Nordic DevZone community covers technical questions:??devzone.nordicsemi.com.?Oh, and don’t forget to enter Nordic Semiconductor’s giveaway contest! Just fill out the?entrance form,?and you're in the running. Good luck!

If you want something to listen to before the next episode, check out Elecia's Making Embedded Systems 2nd edition now as an audiobook! Available on Audiobooks.com, Audible, and Libro.fm among others. Your local library will likely have it through the Libby app?or Hoopla?soon.

Upcoming Show

Our next guest is Kirk Pearson, founder of?Dogbotic. We'll be talking about their book "Make: Electronic Music From Scratch" and a whole lot more. Look for it tomorrow, Thursday the 12th around 4 pm Pacific time.?

Patreon To join the Embedded?conversation?on Slack, support us on?Patreon.

Interested in sponsoring the newsletter or the show? Drop us a line at sponsorship at embedded.fm and let's talk! ??

Sign up to our email newsletter here.