Crashing is not the worst thing your program can do. In fact, I'd argue that it's the second-best thing your program can do, right behind working correctly. Losing data is much worse than crashing, and corrupting data is worse still. Both are strong possibilities once your program's state is something unexpected.
Not all parts of your app make sense to fail-fast. By enforcing this behavior even on peripheral parts of your app, you're taking away the decision making ability about what's important and what isn't from the system designer.
I understand that position, though I still think on the whole explicitness is right. Being able to explicitly disable the check when you know what you want is the right balance, whether it's &+ in Swift or (better, imo) .wrapping_add() in Rust.
And since the UI almost certainly shares data with the rest of the program, bugs in the UI can corrupt the underlying data.
Separation of concerns is great, but if you really want different parts of your system to have different reliability constraints, then you need to truly separate them, for example by running them in different processes. Running them in the same process but having some of the code be more lax about state because it's less important is just begging for horrible bugs.
Indeed, and you might even want to run them on entirely different and independent systems (connected by some type of network/bus) depending on exactly what bits are critical vs. non-critical.
try:
#your code goes here
except:
passThe most convincing take on this I've seen is Erlang/Elixir. You generally fail fast there, but each program is composed of many different, isolated processes. No matter how a single process fails, it won't affect any other independent processes. A stopped process only takes down those processes that depend on it, everything else continues. And Supervisors can restart the failed processes from a known good state again.
> Being able to explicitly disable the check when you know
> what you want is the right balance, whether it's &+ in
> Swift or (better, imo) .wrapping_add() in Rust.
FTIW Swift may not necessarily need to bring down the entire process anyway. When it gets a concurrency story where the compiler can enforce thread boundaries at compile time it could be paired with separate heaps per thread to allow a single thread to abort without aborting the entire process. That would be ideal for the server case.
The decision between "keep on trucking" and crashing is a design choice, and will have to be balanced against other considerations.
And yet again - this is UB because the original writers of the C language knew that the behavior of the hardware would be known to assembly programmers of the time.