I copied the paragraph below from Chapter 5. I think the use of “crash” there may be inappropriate. If I’m flying in an airplane and something goes wrong on the way to my destination, I don’t want to crash it. Instead, I either want to fix the problem(s) on the way to my destination or safely land the airplane short of my destination. So, maybe a controlled descent or crash, short of the destination, is more appropriate than an uncontrolled descent or crash using undetected faulty data?
The land of no return
Some functions are never, ever, intended to return control to the caller. For example, think about a function that is designed to crash an application. Perhaps this sounds strange, so let me explain: if an application is about to work with corrupt data, it’s often best to crash rather than continue into an unknown and potentially dangerous state. The function fatalError("reason to terminate") is an example of a function like this. It prints the reason for the fatal error and then halts execution to prevent further damage.
The term “crash” as used in the book is in reference to an app that is running. An app crashing is simply not the same as an airplane crashing in mid flight. An app crashing is never the intent, but as stated in the paragraph, in certain circumstances, one would actually want this to occur. With respect to an app “crashing”, a more appropriate synonym would be “stopping”, or “shutting down”. It is understood that when using this term, no one is being harmed in the process
LOL You’re probably too young to remember Y2K, Y2K leaves airlines flying on a wing and a pray – The Irish Times but I didn’t worry too much about it because I was a Macintosh person. Back in 1999 many people were working out how to control-descend crashing airplanes in those early hours of January 1, 2000 after their onboard apps “stopped” or “shut down” so that no one would be harmed in the process.
