考虑下面的Java代码片段：
public <T> T create(Class<T> clazz) throws InstantiationException, IllegalAccessException {
return clazz.newInstance();
}
这在Eclipse(Neon.2，JDK 8)中，SonarLint执行静态代码分析。 它提供了重构此内容的建议：
重构此方法以抛出最多一个已检查的异常，而不是：java.lang.InstantiationException，java.lang.IllegalAccessException
此建议的依据是什么最佳做法？ 我知道一般来说，关于检查异常存在一些争议，但是为什么在这种情况下在这里捕获一个并将另一个传递到堆栈中会更好，而不是将它们都传递到堆栈中以便其他东西来处理它们？
此建议的基础是什么最佳实践？
"最佳实践"意味着对问题有一个客观正确的答案。 没有之一。
为什么在这种情况下在这里捕获一个并将另一个传递到堆栈中会更好，而不是将它们都传递到堆栈中以便其他东西来处理它们？
在这种情况下，您不会这样做。IllegalAccessException和InstantiationException都是ReflectiveOperationException的亚型。 如果要将签名减少为单个选中的异常(如检查器所建议的那样)，则可以使用该异常。
通常，统一(通过选择现有超类或重新设计异常层次结构)的论据是调用方需要处理较少的异常。
但与此相反的论点是，当你统一抛出列表时，你对程序员/编译器隐藏了信息。 例如，如果 API 更改为以下内容：
public <T> T create(Class<T> clazz) throws ReflectiveOperationException {
...
}
使用该 API 的程序员不再知道可以抛出哪种反射操作异常。 当你通过捕捉、包装和扔作为新的例外来"统一"时，情况就更糟了。
请注意，我并不是说这两种方法都是错误的。 我想说的是，上下文应该决定你采取哪种方法。 换句话说，诉诸"最佳实践"没有抓住重点。
我同意@David它是基于意见的，尽管在我看来，最佳做法是从基于单一责任原则的方法中抛出一个异常。当抛出多个异常时，听起来该方法被实现为执行多个任务，这不是一个理想的做法，尽管我们每个人都经常这样做。当有这样的需求时，最好通过提及带有适当错误代码或错误消息的问题来引发自定义异常
public class IllegalAccessException
extends ReflectiveOperationException
当应用程序尝试以反射方式创建实例(数组除外)、设置或获取字段或调用方法，但当前正在执行的方法无权访问指定类、字段、方法或构造函数的定义时，将引发IllegalAccessException。