The New Jersey Style.
C's arrays-decay-to-pointers sin is the original sin here, but it's not for nothing that it's taken so long to get systems programming languages that have manual memory management and are memory-safe: that's a hard problem!
The main purpose of any code would be to deal with all possible errors and define them upfront. If, by miracle, your program execution does survive the minefield, you can throw a Success exception.
And it can be worse. IBM, I think it was, back in the 1970s or 80s, said that 80% of the lines of production-ready code dealt with errors - only 20% was doing the actual program functionality.
You have to help other developers understand how and when to use asserts, and then you have to test the developed device very well, so that it won't assert in the field.
Yet if it does assert in the field, it's highly likely that it will get a lot of management attention.
That’s a key point: you don’t want debug-only asserts to be used where you need production error handling.
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.
It was in Latin. "HODIE NATUS EST RADICI FRATER".
A design principle in the OS is that if you pass anything invalid to a syscall, you don't get an error back, you get your process forcibly killed. The thing linked at the start of the paragraph above is about an extension to this principle: if you have a client/server pair running on the OS, and the server gets a request it thinks is invalid, it can forcibly kill the client.
All of which sounds kinda insane, but (as per cjk2's comment in this thread) apparently what actually happens is that in development things blow up all the time and get fixed, and once you get through that phase all those bugs are fixed and everything is very robust.
(But Hubris's use case is quite specific and so far as I know no one is claiming that it would be better if, say, Linux or Windows worked that way.)
"It came from New Jersey" was a pejorative at Sun for "it's [crap code] from SVR4". I bet it's still a pejorative at Oracle for whoever still works on Solaris.
Erlang supports supervision patterns more, though I have little experience there.
"Let it crash" at cell boundaries is also a basic pattern in complex life. I'll bet there's plenty more for programmers to learn about robustness from biology. Doctors and medical researchers too, actually -- they seem too prone to think like "oh here's a kind of damage, guess we have the inside track on this disease now" without understanding it at a level like "here's how the body's self-repair gets overwhelmed".