Java自定义异常选型疑问：为何选择继承NumberFormatException/IllegalArgumentException而非直接继承Exception或RuntimeException？

嘿，我完全懂你的困惑——刚学Java异常的时候，教材只说要么继承Exception要么RuntimeException，结果看到别人用更具体的子类，一下子就懵了对吧？咱们一步步拆解这个问题：

首先得明白Java异常体系的核心设计思路：顶层的Exception和RuntimeException是通用“容器”，它们的子类都是为了对应特定场景的错误类型。就像你去超市买东西，不会直接拿个大箱子装，而是用对应品类的袋子——水果用水果袋，零食用零食袋，这样大家一看就知道里面装的啥。

为什么选NumberFormatException？ #

你的作业是实现bin2Dec，功能是把二进制字符串转十进制。如果输入的不是合法二进制（比如有字母、数字3），本质上就是「字符串不符合数字格式」——而NumberFormatException本来就是JDK用来表示**“字符串无法解析为合法数字”**的异常，语义完全贴合你的场景！

相比直接继承RuntimeException，这么做有两个明显好处：

• 语义清晰：调用你的方法的人，看到抛出BinaryFormatException（假设你自定义的异常继承它），一眼就知道是「二进制格式不对」，而不是空指针、数组越界这类其他运行时错误，排查问题效率高多了。
• 调用方处理更精准：调用者可以针对性地捕获这个异常，比如：

  try {
      int num = bin2Dec("101a");
  } catch (BinaryFormatException e) {
      // 专门处理二进制格式错误
      System.out.println("请输入合法的二进制字符串");
  }
  

  要是你抛出的是泛泛的RuntimeException，调用者只能捕获所有运行时异常，没法区分具体错误类型。

那为什么有人推荐IllegalArgumentException？ #

NumberFormatException本身就是IllegalArgumentException的子类——后者是用来表示**“传入的参数不符合方法预期的要求”**，范围更广。如果你的场景不仅仅是数字格式（比如方法要求参数必须是正整数，但传入了负数），那用IllegalArgumentException更合适；但如果是明确的「数字格式错误」，NumberFormatException是更精准的选择。

至于有些文章说直接继承NumberFormatException不好，大概率是担心和JDK自带的NumberFormatException混淆——比如你自定义的异常也叫这个名字，可能会让调用者误以为是JDK抛出的。但只要你给自定义异常起个明确的名字（比如BinaryFormatException），这个问题就不存在。

为什么不直接继承Exception或RuntimeException？ #

• 继承Exception：这是受检异常，调用方必须显式捕获或者声明抛出。但bin2Dec的输入错误属于调用方的误用（比如调用者没校验输入就传进来），这种错误不需要强制调用方处理——毕竟调用方应该自己确保输入合法，用受检异常反而增加了不必要的代码负担。
• 直接继承RuntimeException：异常太宽泛了，语义不明确。别人看到这个异常，根本不知道是参数错了、格式错了还是其他逻辑错了，调试起来很麻烦。

最后给你个选型小思路 #

下次自定义异常的时候，可以按这个步骤来：

1. 先判断：这个错误是调用方必须提前处理的（比如IO错误），还是调用方误用导致的（比如参数非法）？前者用受检的Exception子类，后者用非受检的RuntimeException子类。
2. 在对应体系里找最贴合你场景的具体异常：比如参数非法找IllegalArgumentException，数字格式错找NumberFormatException，空指针找NullPointerException（不过一般不用自定义这个）。
3. 如果真的没有合适的子类，再考虑直接继承Exception或RuntimeException。

备注：内容来源于stack exchange，提问作者XCELLGUY