我們都知道在開發環境下，程序運行失敗導致崩潰閃退通常會有日志信息告訴我們哪里出錯了，這樣我們就可以快速定位問題。像這種問題都是初級的，即使沒有錯誤日志信息，我們通過單步debug調試或自己加日志信息，看程序走到哪一步出錯了，也能快速定位出來。
隨著工作時間的積累，像空指針異常，數組越界等都很容易避免。而更多的是遇到業務邏輯錯誤，就是實際的運行效果跟你的預期不一致。這些雖然說在程序上沒問題，能正常運行，但其實也是一種錯誤，而且是沒有日志信息，更不存在顯示哪一行了。
舉幾個場景說明一下，比如數據計算錯誤，比如手機頁面列表內容復用錯誤，再比如手機鍵盤彈不出或隱藏不了，甚至是開發人員對需求的理解不一致導致做出來的效果不一樣等等。我們可以對比發現，前面那種代碼運行邏輯錯誤更多的是開發人員自己去發現并解決，而現在這種業務邏輯錯誤更多的是測試人員來發現。現在程序不報錯了，更不會說哪兒有問題了，但這就是有問題，需要解決，這個時候往往需要花大量的時間來定位問題。
其實到這里就能說明程序員遇到很多問題，連運行失敗都不會報，但還是得解決。最后還想補充一點，假若你對自己有要求，有一類問題，像運行不報錯，和預期效果也一樣，但你也得解決，這叫做性能優化。比如一個頁面多請求了幾次服務器，比如一個地方數據沒必要刷新多次等等。
不管哪種問題，日常開發中都會遇到，也許真的會瘋掉，但對于資深開發而言，還不至于程序運行失敗沒有日志而瘋掉。