服务器诊所：编写出色的异常

如何考虑异常
教科书和类似的参考资料一直以来都集中在异常的语法和局部语义方面。通过它们的充分介绍，大多数程序员都能阅读带有异常的代码并能解释其作用。它们所欠缺的是一种对有效风格的感觉。要找到这种感觉，您需要，

重点了解您要求异常为您解决的问题，
如何捕获异常，以及，
如何抛出异常。
本月的专栏文章列举了几个示例来说明如何实现上述三点。

在研究这几个示例之前，不妨采用一种可能与您第一次学习异常时不同的方式来考虑异常，“热热身”。由您喜欢的语言提供的异常系统是不适合于最终用户查看的。相反，可以把异常当作脚手架，在完成应用程序之后，再“拆除”这些“脚手架”。也许您曾在课堂上学过阅读这样的异常，如下所示

caughtexceptioninmain()
java.lang.SomeException:uglyinput
at...
当然，这个技巧对程序员是有价值的。可是它绝不能被强加给最终用户。一个完整的应用程序应该从来不说“有异常”；所有呈现给最终用户的报告都应该用下面的这种本机语言来写，或许更接近于这样

Theconfigurationfile'folder/thing.cfg'
appearstobecorrupt,asline#17cannot
beparsed.
正是这种清晰性对应用程序的安全性施加了直接的压力。其原因在于：用户及其管理员一次又一次地证明他们对不能理解的事物的反应，是简化系统直至得到自己期望的行为。如果他们读到“未发现文件（filenotfound）”，他们会随意地从别处复制一些文件，而不考虑特权或许可权。而保证应用程序安全性的最可靠的方法之一就是使应用程序工作，这样用户才会理解它的运作。聪明的用户会因为急于“让程序工作”而破坏几乎所有安全性设置。

不是所有程序员都认同我这种观点。有不少高级软件工程师冷静地提议说，用户输入错误的数据或错用应用程序都是咎由自取。我在这里不是要讨论这种态度的道德问题；只是注意到，在开发人员和最终用户采取这种互相对立的姿态时，安全性正在不断地被破坏。

因此，在某个特定开发项目中，使用异常的第一步，也往往是最容易被忽视的一步，就是确定程序对异常的需求。这一点一定要搞清楚。当客户或主管在指示程序应如何处理格式良好的输入数据时，抓住机会，对万一发生错误时程序的具体操作细节同他们达成共识。给自己足够的时间去会见客户。想象一下：最终客户可能会把同程序“接触时间”的大部分都消耗在查看程序所显示的错误消息上。这并不是骇人听闻，对许多应用程序来说“正常”操作是相当快的，而对于错误的响应，人们需要花不少时间来思考。错误消息及对应操作同程序的其它部分相比，值得花同样多的技术。

事实上，我会对那些让最好的人才集中精力于错误处理方面，而不是传统编程中比较“花哨”的方面（比如图形用户界面（GUI）外观编程）的项目，更感到高兴。理由在于：一个有错误但带有优秀的错误处理机制的应用程序，比近乎完美但其错误处理机制却不友好的应用程序，更能赢得最终用户的欢心。

在完成了第一轮需求分析后，您手中拥有的这些叙述性说明会使程序的异常处理设计更为合理且更有价值。现在的挑战则是这篇专栏文章的读者所感兴趣的技术问题。

捕获
Python作为一种方便的工具，可用来表达示例用法。我经常遇到类似于这样的缺陷：

清单1.不匹配的捕获

try:
process(some_file)
except:
alert("errorinopening"'%s'%some_file)



发现问题没有？异常的语法和语义不匹配，这有点类似于一个公务员，在向选民承诺要注意他们最关心的问题，尤其是游泳池开放时间。尽管这样的语句形式上正确，其失衡却会使听众感到震惊，暗示有更深层的问题。

上面这个不匹配的捕获也存在类似问题：它捕获了所有错误，但仅仅只报告了“打开文件时出现错误（errorinopening）”。这样写会好一点：

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有