我需要更穩定的應用程式。

最近遇到很多不明白原因的錯誤，把自己搞得不知所措了。總結了一些原因，這些都應該是在開發中十分注意的。
1、不能假設極好情況下可以啟動並執行程式就算完成了。特別是網路應用程式，在網路環境十分糟糕的情況下，可能與最初的需求相差極遠，或者完全就不是一回事了。所以，你的應用程式不能僅僅在LAN裡可以運行就行了。應該說，可以在LAN裡啟動並執行程式，是最不安全的。我是真的怕了。
2、不能怕麻煩而放棄寫日誌或者錯誤記錄。因為前些時候一些功能要求的急，所以就匆匆了事，做了個DEMO，誰知道就是這個DEMO，把我搞的不知所云。主要原因就是程式沒有輸出，沒有日誌，就是在後台做文傳輸工作。結果是100%的失敗。最後為了發現錯誤，又不得不重新寫日誌，寫調試輸出。最後還是從日誌裡發現小錯誤。因此，如果一個功能在短時間內無法完成，就不要做了。決對不能為了應負要求而寫不合格的DEMO。
3、TRY和CATCH結構一定要合理。很多時候為了得到異常或者讓程式可以正確的運行，就是CATCH了所有的錯誤。結果是不可預料的，有時候可能會出現比TRY得到的錯誤更可怕。簡單的一個例子：線上程裡，它會CATCH到Abort異常，而這個異常是應該讓線程終止掉的。結果CATCH到後，做了錯誤處理，而沒有終止它，結果可想而知。當然還有很多。所以，好的做法是明確的CATCH你所想要的異常。在不明確的情況下，請在做了資源清理後，重新拋出異常吧，讓應用程式的其它部份來處理它，或者讓異常終止程式而明確的知道這裡有一個未知異常，然後做進一步處理。
4、資源使用要明確的分配以及顯示的釋放。在前幾天遇到的錯誤中，就有一個是因為多線程訪問同一個檔案而出現死結。原因是一個線程在它死掉前沒有安全的釋放檔案控制代碼。而修改這一錯誤的簡單方法就是明確的顯示釋放檔案，應該是在使用完檔案後立即釋放，或者是在異常出現後立即釋放，而不能等線程終止的時候去釋放。
以上這些就是這幾個星期遇到的錯誤總結。發現錯誤和修改錯誤佔用了大量的時間，而錯誤卻往往是一點小問題。寫程式，小心了。