Java

Java Exception 历史回顾 前言 本文从 Exception 的起源讲起，试图帮开发者建立对 Java、Kotlin 编程语言异常处理机制的感性认知。文章内容出自个人理解，如有纰漏，还请各位看官斧正。 1990 年前后， Sun 公司的工程师团队在项目开发中经历了 C++ 的诸多痛点，对此 Sun 公司内部成立了 Stealth 计划小组（后改名为 Green 计划小组）来解决这些痛点问题。小组起初进行了多种尝试：有切换编程语言到 NexT 的；也有尝试改进和扩展 C++ 的，但都宣告失败。最终小组内的 James Gosling ( Java 之父) 决定创造一个新的编程语言来解决问题。他以办公室外的橡树为名，把这一编程语言称为 Oak，随后因商标原因将其更名为 Java。 Java 语言的开发过程中广泛借鉴了 C/C++ 的特性，C++ 中的异常处理机制也被沿用了下来。 C++ 语言中的异常 异常：表示程序中意料之外，情理之中的一类错误。 C++ 中的异常处理是一种条件转移机制，当程序在运行过程中遇到 throw 关键字时，会中止当前的程序代码块并跳转到最近的 catch 代码块执行后续操作。这一行为对 C 语言中的 goto 机制，以及汇编语言中的转移指令（如：jmp）。 C++ with Exception C/C++ with Goto 在 C 语言体系中，goto 因过于灵活和难以调试，常被诟病为邪恶的。常见的规避手段是使用 int 类型的返回值表示函数的执行状态，通常用 0 表示执行成功，非0表示执行失败。但上述做法违背了函数返回值的用途，导致大量库函数不得不增加额外的形参作为真实的返回值，如下所示：...

在看Java HashMap工作原理及实现这篇文章时，发现博主在断点模式下来观察hash冲突的效果挺好的，随后便想在IntelliJ IDEA中也试下。 我们先来看下HashMap.Node的代码，有4个成员变量。 1 2 3 4 5 6 7 static class Node<K,V> implements Map.Entry<K,V> { final int hash; final K key; V value; Node<K,V> next; //省略后续内容 } 如下图所示，对于HashMap.Node类型的对象，IDEA默认只显示了key，value这两个成员变量。 原因在于IDEA默认将HashMap.Node视为了Map.Entry，那么如何在Debug时以HashMap.Node的类型来查看该对象其他变量呢？ 方法有二： 一. 在debugger的Variables面板中，右键该对象，找到View As选项，选择其中的Object，然后就可以看到该对象的所有属性了。 二. 采用第一种方式时，每次Debug都需要手动指定其类型，较为繁琐。对于常用的类，我们也可以在View as时点击Create按钮，为其新建类型。这样的话以后每次Debug时，无需任何设置就能在Variables面板内直接看到其准确类型的所有属性。 Create过程也很简单，在Java Type Renders窗口内，设置HashMap$Node对应的完整类名即可，如下图所示。 最后看一下，在View as中Create了HashMap及HashMap.Node后的效果。 现在已经能看到类中的所有成员变量了，那么对于静态变量该如何查看呢？这个也很简单，同样在此处右键，点击Customize Data Views… 然后在Static fields和Static final fields的选项前打勾即可~ 以HashMap为例，在选中了Static fields和Static final fields的选项后，所有的静态变量也显示出来了 ：）