阅读了第四章和第五章的一部分，其中有关异常让我印象深刻，特别是自己也刚学到java异常处理部分，有关自定义异常类等。
在编程的时候，如果他不可能发生，用断言确保他不会发生，只要最后结果不出来，那么你所认为的不一定就是完全正确的，而你所要做的就是，增加代码来检验他，最容易的办法就是使用断言，当然，绝对不要把必须的代码放在断言里面，因为断言可能会在编译时被关闭，并且断言不等于真正的错误的处理，因此不能用断言来代替真正的错误处理，断言检查的是绝不应该发生的事情。
让断言一直开着，就像书中的那个说法一样，断言给代码增加了一些开销，因为他们检查的是绝不应该发生的事情，，所以只会有代码中的bug出发，一旦代码经过了测试仪并且发布出去，他们就不再需要存在，应该被关闭，以使代码运行的更快，断言只是一种调试设施，这样的说法误导了人们对于断言的看法，而且本身也存在重大的错误，在复杂的程序中，你不会那么轻易的找到你的bug所在，其次，你的程序在运行的时候还会发生一些不可预料的事情，你的第一条防线是检查任何可能的错误，第二条防线是使用断言设法监测你疏漏的错误。
异常应该保留给意外事件，例如在文件读取的时候是否有文件，删除文件的时候是否存在，创建新文件的时候是否已经存在文件等，错误处理器是检测到错误时调用的例程。在配平资源的时候要有始有终，在Java中，当try块含有finally子句时，如果try块中有任何语句被执行，该子句中的代码就保证会被执行，是否有异常抛出没有影响。但你无法配平资源的时候，在动态数据结构的程序中，一个例程将分配一块内存区，并把它连接进某个更大的数据库中，这块内存可能会在那里呆上一段时间。注重实效的程序员谁都不信任，包括我们自己，所以我们觉得，构建代码，对资源却是得到了适当释放进行实际检查，这总是一个好主意，对于大多数应用，这通常意味着为美中资源类型编写包装，并使用这些包装追踪所有的分配和解除分配在你代码中的钉钉地方，程序逻辑将要求资源处在特定的状态中：使用包装对此进行检查。
生活不会停步不前，同样，我们编写的代码也不会，为了让我们赶上今天近乎疯狂的变化步伐，我们必须要尽一切努力编写尽可能狂送灵活的代码，否则，我们会发现我们的代码变得过时，或者是太脆弱，以至于难以修理，并且最终可能会在想着未来疯狂的突进中掉队。要尽量的降低代码的耦合度（代码模块间的依赖关系），让分离的概念保持分离，一种办法是少写代码，改动代码会让你引入bug的可能性增大，把各种细节移除代码，那样就可以更安全，更容易的改动他们，你应该注意你与多少其他模块交互，而且更重要的是，你怎样开始与他们交互的，当我们要求某个对象完成特定任务时，我们想要爱软件中遵循同样的模型，我们不希望这个对象给我们一个第三方对象，我们必须对其加一处理才能获得所需的服务。
再多的天才也无法胜过对细节的专注，细节会弄乱我们整洁的代码，特别是他们经常变化，没当我们必须去改动代码，以适应商业逻辑，法律，或管理员个人一时的口味的某种变化时，我们有破坏系统，引入新bug 的危险。不要让你的项目或者你的职业生涯走上渡渡鸟的道路，他们不能适应人类和他们的家畜的出现，很久就灭绝了，是人类记载的第一起物种的灭绝。时间是软甲架构的一个常常被忽略的方面，吸引我们的只是进度表上的时间，相反我们谈论的是作为软件自身的一种设计要素的时间的角色，时间有两个方面对我们很重要，并发和次序。我们在编程的时候，往往是线性的，总是先这个，再这个，这样会带来时间的耦合：在时间上的耦合，方法a必须总是在方法b之前调用；同时只能运行一个报告；再接受到按钮点击之前，你必须等待屏幕重画滴必须在嗒之前发生。
