Here's my take. Asserts are a kind of error handling. They handle situations where the code can tell that it's off the rails. It might be off the rails due to a hardware error or a software implementation error, e.g., a 'can't happen' situation.

We didn't have debug-only asserts. Asserts were enable in the software we verified and shipped.

It took a while for developers to be able to determine when a situation called for an assert, and when it called for what might be called traditional error handling.

The strategy of shipping with asserts enabled kind of worried some folks. They were concerned that it might assert in front of a customer. I understand the concern, but in our domain, if you're doing an OB exam with the ultrasound system and you have a choice of asserting or showing a femur length measurement of -1039cm, which is better?

We didn't have many asserts in the field. We had a lab where we had about 25 - 30 ultrasound machines running embedded tests constantly. Each machine was connected to a JTAG debug board, so we could flash new code into the system and so we could set a breakpoint on the assert routine itself and save a "core dump" for subsequent debugging without having to try to reproduce the system state that led to the assert.

The whole lash-up evolved over a period of years. It worked well, so far as I know.

One mitigating factor was that our systems were class B devices. They were always supposed to be used by a medically trained professional that had the ability to take over if the system asserted, or power failed, etc.

Happy to try to answer any questions about this.

I'm sure this isn't an original idea, but I've always understood that an assert is intended for the developer, an error is intended for the user. Sometimes an assert can be by itself because you know that the invalid condition will be 'absorbed' (for want of a better word), and sometimes an assert is followed by an error because you want the developer to see more than what the error will display to the user.