读《构建之法》第四章和十七章有感

第四章

我看了这一段文字：异常（Exceptions）是在“异乎寻常”的情况下出现的，它的设置和处理都要花费“异乎寻常”的开销，所以不要用异常作为逻辑控制来处理程序的主要流程。

问题：异常具体在什么时候出现？使用异常时要注意什么？

资料查找： Java采用违例(Exception)处理机制来进行错误处理。 违例机制的一个好处就是能够简化错误控制代码， 我们再也不用检查一个特定的错误， 然后在程序的多处地方对其进行控制。 此外， 也不需要在方法调用的时候检查错误（因为保证有人能够捕获这里的错误）。 我们只需要在一个地方处理问题：”违例控制模块”或者”违例控制器”。 这样可有效减少代码量， 并将那些用于描述具体操作的代码与专门纠正错误的代码分隔开。
一个完整的违例例子：

[java] view plain copy

1. public void throwTest() throws MyException {  
2. try {  
3.         ...  
4. } catch (SQLException se) {  
5.         cat.error("", se);  
6.         throw new MyException(se.getMessage());  
7. } catch (Exception e) {  
8.     cat.error("", e);  
9. } finally {  
10.         ...  
11. }  
12. }  

        如果一段代码有可能会抛出违例可以用try {} catch {}来处理。 被catch到的违例可以再抛出， 也可以转换为其它类型的Exception抛出。 finally块里面的代码总会被执行到的， 不管前面是否已经throw或return了。
        Throwable是所有违例的基类，它有两种常规类型。其中，Error代表编绎期和系统错误，我们一般不必特意捕获它们。Exception是可以从任何标准Java库的类方法中掷出的基本类型。看上面看，如果是Error的子类或是RuntimeException的子类这种违例有一定的特殊性，可以说我们可以当它们不存在，当这种违例抛出的时候，我们可以不catch它，也可以不在方法上throws它。RuntimeException一般代表的是一个编程错误，是完全可以避免的。

自己理解：如果代码书写完全正确，但因外界环境或者用户操作仍然可能发生的事件，都不适合用断言，可以使用异常。至于异常，对不同语言来说含义不同。不可一概而论,有很多具体情况分析。因为使用了Exception之后是要影响一些效率的， 所以Exception不能滥用。一般的不要用Exception来控制流程， 其次不要循环体内使用。我们可以从Exception或直接从Throwable继承写我们自己的Exception， 然后根据需要抛不同种类的Exception。

 

我看了这一段文字：如何验证正确性？那就要用断言（Assert）。断言和错误处理是什么关系？

问题：断言（Assert）是什么？如何使用断言（Assert）？什么时候使用断言（Assert）？

资料查找：断言在软件开发中是一种常用的调试方式，很多开发语言中都支持这种机制。一般来说，断言用于保证程序最基本、关键的正确性。断言检查通常在开发和测试时开启。为了保证程序的执行效率，在软件发布后断言检查通常是关闭的。断言是一个包含布尔表达式的语句，在执行这个语句时假定该表达式为true；如果表达式的值为false，那么系统会报告一个AssertionError。

断言可以有两种形式：

assert Expression1;
assert Expression1 : Expression2;
Expression1表示一个boolean表达式，Expression2表示一个基本类型、表达式或者是一个Object，用于在失败时输出错误信息。

要在运行时启用断言，可以在启动JVM时使用-enableassertions或者-ea标记。要在运行时选择禁用断言，可以在启动JVM时使用-da或者-disableassertions标记。要在系统类中启用或禁用断言，可使用-esa或-dsa标记。还可以在包的基础上启用或者禁用断言。

注意：断言不应该以任何方式改变程序的状态。简单的说，如果希望在不满足某些条件时阻止代码的执行，就可以考虑用断言来阻止它。

自己理解：断言的使用方法在于判断程序的正确性并且有时候可以阻止其错误的运行。assert用在那些你知道绝对不会发生的事情上，但是因为人总是会犯错误，保不准你写出来的东西跟你想的不一样。所以assert用来捕捉的是程序员自己的错误。断言表示程序写错了，只要发生断言失败，意味着至少有一个人得修改代码，它的性质如同编译错误。

第十七章

我看了这一段文字：在与公众利益一致的原则下，软件工程师应当保证其职业的完整和声誉。软件项目的经理和领导人员应赞成和促进对软件开发和维护合乎道德规范的管理。

问题：软件工程师的道德行为规范具体是怎么样的？有没有具体说明。

资料查找：目前，计算机已经成为推动经济、工业、政治、医疗、教育、娱乐和整个社会发展的核心技术。而在这当中，软件工程师通过亲身参与或者教授软件系统的分析、说明、设计、开发、授权、维护和测试等实践工作，为社会做出了巨大贡献。正是由于他们在软件系统开发中起到的重要作用，软件工程师有很大的机会去造福或者危害社会，并有能力去促使或影响他人造福或者危害社会。为了尽可能确保这些影响是有利于社会的，软件工程师必须承诺自己所从事的职业能造福社会, 并且能够得到大众认可尊重。这一承诺要求软件工程师必须遵守下列《职业道德规范和实践标准》。

这一《规范》包括了有关职业软件工程师的行为和决断的八项准则，涉及软件工程方面的实际工作者、教育工作者、经理、主管、决策制定者以及相关的受训人员和学生。这些准则指出了个人、小组和团体参与软件工程的道德责任关系，以及这些关系中的主要责任。每一条原则都是对这些关系中的责任做出的说明。这些责任覆盖了软件工程师的人性，他们对那些受软件工程师工作影响的人们的特别关照，以及软件工程实践的独特因素。《规范》规定任何已经成为或者想成为软件工程师的人必须遵守这些原则。

本规范的每个部分都不应该被断章取义, 孤立使用去判断人们有意或无意犯下的错误。因此这些原则和条款并不是非常完善详尽的。在实际使用过程中，不应当将条款中的可接受部分和不可接受部分分开来讲。同时，《规范》也不是一个简单的道德算法，可以产生所有的道德上的决定。在某些情况下，一些标准可能会相互抵触或者与其他地方的标准相互抵触。在这种情况下，就要求软件工程师能够运用自己的道德判断能力，在特定的情况下做出最符合《规范》的行为。

解决道德冲突最好的方法是对基本原则进行全面的思考，而不是去盲目的依靠一些具体条目。这些原则应当会促使软件工程师们去更广泛的思考哪些人是他们工作的受众，去思考他和他的同事是否给予其他人足够的尊重，去思考对他们工作有足够了解的公众会如何看待他们的决定，去思考他们的决定如何影响最小，以及去思考他们的行为是否符合一名优秀的专业软件工程师的标准。在所有这些思考中，对公众健康、安全与福利的关注是最主要的。也就是说，“公众利益”是《规范》的核心。

由于软件工程这一行业的多变性与苛刻性，它需要一份相关的规范去应对自身不断出现的新情况。《规范》记录了这个行业的道德立场与标准。因此即使是对于这样普遍性的要求，《规范》依然为软件工程师以及他们的经理提供了支持。《规范》无论是对团队中的个人还是团队本身来说都提供了一个道德基础。《规范》也规定了那些对软件工程师或其团队来说道德上不正当的要求。

这份《规范》不仅仅能用来对那些遭到质疑的行为的性质进行判断，它还具有非常重要的教育功能。由于这份《规范》表达了这个行业对于职业道德的一致认识，因此它是教育公众和那些有抱负的专业人员有关软件工程师道德责任的一种工具。

自己理解：软件工程师的道德规范是作为一名软件工程师极其重要的一部分，所有从事软件行业的人都必须积极遵守，共同维护软件行业。软件工程师应当遵守道德规范，致力于使分析、规范、设计、开发、 测试和维护软件的一个有益的和受人尊敬的职业。