I have worked with code (in PHP) that didn't use "fail fast" approach and didn't even log most warnings and notices. App didn't crash but sometimes randomly ret

I have worked with code (in PHP) that didn't use "fail fast" approach and didn't even log most warnings and notices. App didn't crash but sometimes randomly returned invalid results. Of course, nobody fixed this because after reloading the page the error could be gone. If you ignore errors or warning you just get low quality code as a result. Maybe this code will corrupt your database content, who knows. It is safer to stop the code if something seems wrong. Also I remember reading somewhere that the earlier you find the error the cheaper it is to fix it. > why did my app just disappear, did I do something wrong? Usually operating system reports that there was an error in the application. If the application crashes often, the users will complain to developers and they will fix it. > Debuggers are a terrible user experience, we don't need to force every user to live in a debugger You should test your app properly before releasing it. > There are disastrous consequences to bad multi-threaded code during "fail fast" teardowns of threads not privy/cause to the error. I cannot agree with this. Usually the OS releases all locks, closes all files, frees memory when the process terminates. I don't see what can go wrong here and how you can get a deadlock because some process has terminated. Also if you use locking you should add some kind of timeout. For example, MySQL has lock timeouts and can even detect and fix deadlocks. > "Fail fast" in day-to-day operation isn't the right solution, at the very least for making users possibly hate you because you'll never properly handle 100% of exceptions The users will probably hate you more if the app will silently hang or show incorrect data.