> Moreover, crashing on assertions has the unintended consequence of making programmers afraid to write assertions. In a past life, when I worked on C++ servers

> Moreover, crashing on assertions has the unintended consequence of making programmers afraid to write assertions. In a past life, when I worked on C++ servers... The client side rendition of this philosophy exists too. Some client engineers consider it bad form to allow the user to see the application crash. So much so that they'll actually advocate for harmful things like littering the codebase with default values so that when something bad happens the application just keeps on chugging along in a state that nobody every accounted for because doing who knows what to the user's data because they hid errors in default values. It's really really sloppy. I am definitely team let the user see the crash. Then they know something went wrong, can be alert, and try again in needed. They can report the problem so the devs are aware or the dev's crash tooling will automatically do it. And, ultimately, the issue will get fixed. (The original version of this philosophy was probably "don't let the user see the app crash, handle the error properly, showing something helpful to the user if necessary, instead". But when adopted by time-constrained product engineering teams, sadly nobody cares about properly handling error states.)