为何try-catch未生效？排序触发Comparison方法违反约定错误

我来帮你拆解下这个问题——你遇到的不是catch块没生效，而是你的比较器逻辑违反了Java排序算法要求的比较器通用契约，所以才抛出了java.lang.IllegalArgumentException: Comparison method violates its general contract!异常。

为什么catch块看起来"没用"？ #

其实当解析无效工号时，你的catch块确实执行了，也返回了-1，但问题出在这个返回值破坏了比较器必须遵守的规则。举个例子：

• 假设员工A的工号无效，员工B的工号有效：
  • compare(A, B)：A解析失败，catch返回-1（认为A < B）
  • compare(B, A)：B解析成功，A解析失败，catch返回-1（认为B < A）
    这就直接违反了对称性规则——如果a < b，那么必须满足b > a，排序算法检测到这种矛盾，就会抛出异常终止排序，而不是继续执行。

比较器必须遵守的3个核心规则 #

Java的Comparator接口要求实现类必须满足以下三个契约，否则排序算法（比如Java 7+默认的TimSort）会抛出异常：

1. 自反性：compare(a, a)必须返回0
2. 对称性：如果compare(a, b) < 0，则compare(b, a)必须> 0；如果compare(a, b) == 0，则compare(b, a)也必须== 0
3. 传递性：如果compare(a, b) < 0且compare(b, c) < 0，则compare(a, c)必须< 0

修复方案：让比较器满足契约 #

我们需要调整逻辑，把无效工号统一放到排序结果的末尾（或开头），同时保证所有规则都被满足。下面是修正后的代码：

public int compare(Employee t, Employee t1) {
    // 标记两个员工的工号是否有效
    boolean tBadgeValid = false;
    boolean t1BadgeValid = false;
    Integer tBadge = null;
    Integer t1Badge = null;

    // 分别解析两个工号，避免互相影响
    try {
        tBadge = Integer.parseInt(t.getBadgeNumber());
        tBadgeValid = true;
    } catch (NumberFormatException e) {
        // 工号无效，不做额外处理
    }

    try {
        t1Badge = Integer.parseInt(t1.getBadgeNumber());
        t1BadgeValid = true;
    } catch (NumberFormatException e) {
        // 工号无效，不做额外处理
    }

    // 分情况处理：
    if (tBadgeValid && t1BadgeValid) {
        // 两个工号都有效，正常按数值比较
        return tBadge.compareTo(t1Badge);
    } else if (tBadgeValid) {
        // t有效，t1无效 → t排在前面
        return -1;
    } else if (t1BadgeValid) {
        // t无效，t1有效 → t排在后面
        return 1;
    } else {
        // 两个都无效，视为相等，返回0
        return 0;
    }
}

修复逻辑的合理性说明 #

这个方案完美满足了比较器的所有契约：

• 自反性：同一个员工比较时，无论工号是否有效，都会返回0
• 对称性：如果compare(A,B)=-1（A有效B无效），则compare(B,A)=1（B无效A有效），完全对称；如果两个都无效，互相比较返回0
• 传递性：比如A有效、B无效、C无效 → compare(A,B)=-1，compare(B,C)=0，则compare(A,C)=-1，符合传递性

额外建议 #

尽量不要在compare方法中执行可能抛出异常的操作，最好提前预处理员工列表：

1. 遍历员工列表，提前标记每个员工的工号是否有效
2. 把有效工号的数值提前解析并存储在Employee对象中
   这样排序时的比较逻辑会更简洁，也避免了在排序过程中处理异常的开销。

内容的提问来源于stack exchange，提问作者Bob Stout