zoukankan      html  css  js  c++  java
  • 我需要更稳定的应用程序。

    最近遇到很多不明白原因的错误,把自己搞得不知所措了。总结了一些原因,这些都应该是在开发中十分注意的。
    1、不能假设极好情况下可以运行的程序就算完成了。特别是网络应用程序,在网络环境十分糟糕的情况下,可能与最初的需求相差极远,或者完全就不是一回事了。所以,你的应用程序不能仅仅在LAN里可以运行就行了。应该说,可以在LAN里运行的程序,是最不安全的。我是真的怕了。
    2、不能怕麻烦而放弃写日志或者错误记录。因为前些时候一些功能要求的急,所以就匆匆了事,做了个DEMO,谁知道就是这个DEMO,把我搞的不知所云。主要原因就是程序没有输出,没有日志,就是在后台做文传输工作。结果是100%的失败。最后为了发现错误,又不得不重新写日志,写调试输出。最后还是从日志里发现小错误。因此,如果一个功能在短时间内无法完成,就不要做了。决对不能为了应负要求而写不合格的DEMO。
    3、TRY和CATCH结构一定要合理。很多时候为了得到异常或者让程序可以正确的运行,就是CATCH了所有的错误。结果是不可预料的,有时候可能会出现比TRY得到的错误更可怕。简单的一个例子:在线程里,它会CATCH到Abort异常,而这个异常是应该让线程终止掉的。结果CATCH到后,做了错误处理,而没有终止它,结果可想而知。当然还有很多。所以,好的做法是明确的CATCH你所想要的异常。在不明确的情况下,请在做了资源清理后,重新抛出异常吧,让应用程序的其它部份来处理它,或者让异常终止程序而明确的知道这里有一个未知异常,然后做进一步处理。
    4、资源使用要明确的分配以及显示的释放。在前几天遇到的错误中,就有一个是因为多线程访问同一个文件而出现死锁。原因是一个线程在它死掉前没有安全的释放文件句柄。而修改这一错误的简单方法就是明确的显示释放文件,应该是在使用完文件后立即释放,或者是在异常出现后立即释放,而不能等线程终止的时候去释放。
    以上这些就是这几个星期遇到的错误总结。发现错误和修改错误占用了大量的时间,而错误却往往是一点小问题。写程序,小心了。
  • 相关阅读:
    171. Excel Sheet Column Number (Easy)
    349. Intersection of Two Arrays (Easy)
    453. Minimum Moves to Equal Array Elements (Easy)
    657. Judge Route Circle (Easy)
    CSS笔记
    保存页面状态
    UI开发总结
    ubuntu 下配置munin
    反向代理配置
    JavaScript 高级程序设计第二版
  • 原文地址:https://www.cnblogs.com/WuCountry/p/426212.html
Copyright © 2011-2022 走看看