《断言式编程》这一章教我如何主动地、有章法地处理程序中的“意外”情况。
1. 断言式编程：明确你的假设
“断言式编程”的核心思想是：用代码明确地表达你对程序状态的假设，如果假设被违反，就果断地报错。 这就像是代码里的“检查点”。
C/C++中的断言： 在C/C++中，我们使用assert宏，它通常在Debug模式有效，在Release模式会被忽略。它适合检查那些“绝对不应该发生”的情况，比如一个内部算法的中间状态。
int divide(int a, int b) {
assert(b != 0); // 我们认为调用者绝不会传0，这是内部契约
return a / b;
}
Java中的断言： Java也有assert关键字，但用法和地位有些不同。在Java中，更普遍、更强大的工具是异常机制。断言通常用于检查非公有的前置条件、后置条件和内部不变性。但在Java的世界里，我们更倾向于用异常来建立“契约”。
2. 异常：正式的契约
Java的异常机制将“错误”提升到了语言层面，形成了清晰的“契约”。这比C中通过返回值判断错误的方式要优雅和强大得多。
受检与非受检异常： 这是Java异常体系的核心概念，体现了不同的契约。
受检异常： 像是方法签名的一部分，是显式契约。比如，FileInputStream的构造器声明会抛出FileNotFoundException。这是在告诉所有调用者：“我可能会失败，原因可能是文件找不到，你必须处理或声明继续抛出这个异常。” 这强制程序员考虑并处理潜在的已知问题，增强了程序的健壮性。
非受检异常： 通常表示编程错误，是隐式契约。比如NullPointerException, IllegalArgumentException。它们对应着“快速失败”原则。我们假设调用者会遵守规则（不传null，不传非法参数），如果他们违反了，我们就用非受检异常来“惩罚”他们，立即终止程序运行。
我的实践：定义自己的异常。
3. 何时使用异常？
书中建议“只在异常情况下才使用异常”。这让我反思，不能滥用异常来控制正常流程。比如，用try-catch来包裹一段代码以跳过错误继续执行，这就像是把“死程序不说谎”原则又捡了回来，会让调试变得困难。异常应用于处理那些打断正常流程的、意外的、但可知的错误。
总结与联想：
这一章让我认识到，优秀的错误处理不是事后补救，而是事先设计。通过断言和异常，我们为代码建立了清晰的“契约”，明确规定了每个模块的责任和边界。从C语言的错误码，到C++的异常（较少用），再到Java强化的异常体系，我看到了语言设计在帮助程序员构建更可靠软件方面的努力。
