As so often, it really depends. Let's say you've just detected that you're going to send incorrect data because you've ended up in an indeterminate state. If t

As so often, it really depends. Let's say you've just detected that you're going to send incorrect data because you've ended up in an indeterminate state. If the remote end is going to ignore that data anyways, would it really be such a bad idea to keep running? Do you really want to go down in order to ensure that a remote who's ignoring your data can get correct data to ignore? Of course you never know what sort of effect the corrupt data is going to have, so it's always hard to make that decision. Like that issue with libraries linking against objective-c frameworks that has crept up with High Sierra and broke most of the Ruby world: Yes. The usage was incorrect. Yes, forking after threads are launched leads to undefined behavior, yes, knowing about it is a good thing. But: So far the crashes have been rare in the common use-cases (or they would have been fixed), so High Sierra's change to blow up loudly when it detects the misuse has actually caused a lot of trouble for people where things worked fine before. To the point where many Ruby developers were complaining about High Sierra "breaking" their workflow and recommending against upgrading. The new check is totally justified though. The existing forking behavior was wrong and it could have lead to crashes down the line. It didn't though. And now people are forced to fix something that was never an issue to begin with. It's a fine line to walk and while I generally prefer things to blow up as they go wrong, sometimes I catch myself wishing for stuff to just continuing to work. On some self-reflection, I come to the conclusion that I want my cake and eat it too.