论接口/特征方法不设计错误返回带来的问题，以及为什么很多标准接口/特征方法不设计错误返回

Question

-->在编程中常有重写方法、为方法特供自己特有的实现的情况，例如子类重写父类非抽象方法、实现类实现接口（java的interface）、实现特征（rust的trait）等。
-->
--> 而一个子模块的方法中如果遇到一些可预料的错误：如用户输入不合法、文件不存在等错误，一般是需要将这个错误反馈给上层处理。而不应该是自己擅自主张直接进入panic恐慌模式来终止程序或者线程
-->
！！！【本问题不讨论编程错误引起的错误情况：如数组越界访问，使用悬垂引用、NPE等，在java的语境中，”错误“一词没有特殊说明，不表示java中的Error类】
-->
-->不同语言特供了自己的方式来反馈错误。在java中常用受检异常来抛出这种异常又或者用是Optional，而C和rust都偏向与使用返回值来反馈这种异常（rust中，返回Result<T, E>或Option）。这些反馈错误的方式往往就表示在方法的签名中。
-->
-->一种重现父类方法的方法它往往是根据自己的业务有自己的实现方式，而这是实现方式决定了这个方法是否会抛出异常和会抛出哪些异常。作为一个父类方法、接口方法或者trait方法它的函数签名是静态的，也就是说它是否会反馈错误，怎么反馈错误都是写死固定的。同时这些父类方法、接口方法或者trait方法，也不能确定使它们被重写的方法是否会抛出错误和会抛出哪些错误，那如果说这些父类方法、接口方法或者trait方法如果要能支持重写方法能抛出自己的与业务相干的错误。那所有的父类方法、接口方法或者trait方法难道不应该都要在签名中设计错误的反馈方式吗？但是很显然，许多标准库/包中的接口和trait并没有这么做，很多方法签名上根本没有涉及任何的错误返回方式，这是为什么呢？这样做不就是在限制具体实现的功能吗？因为不能反馈错误，所以所有可能出错的实现都不能重写那些父类方法、接口方法或者trait方法，这个限制实在令人太失望了。
-->
-->在java中有些人会建议使用RuntimeException去包装这些错误然后再抛出，这样方法签名就可以不用写明这个错误，就和接口方法（父类方法）的签名达成一致。但是我认为这个方法真是太糟糕了，令人头皮发麻。因为接口方法（父类方法）的文档是不会说明这些实现方法（重写方法）可能犯下的具体错误的，其他方法在使用这个接口方法（父类方法）是无法知道会出现什么错误的，因此使用这个接口方法（父类方法）的方法会出现什么样错误也是未知，这给人感觉就像程序的任何一个函数都会出现错误，并且还不知道它的具体错误类型，正如开头所说的那样，他是程序运行中会出现的正常情况，因此我们应该要求程序去处理这种错误，但是上层的代码要处理这些错误要先知道哪会发生错误和有哪些错误。但是使用RuntimeException去包装这些错误后，这个问题就难以回答了。如果有人尝试经过认真的分析程序中所有被RuntimeException包装的错误的源头和传播路径（这必然要深入了解方法的具体实现），在上层的代码中找到了所有可能会出现这些错误的范围，那真是一件辛苦的事，但是更可怕的是，如果在将来又有一些新的RuntimeException包装的错误的源头出现或者消失，那么上层的代码中可能会出现这些错误的范围又将会改变，你又要重新小心翼翼地去分析一遍这些错误的传播路径，这真是一件非常不愉快的事情。为了削弱这种耦合，有的人可能就直接将上层代码整个都泡在try-catch块中，防止有漏网之鱼，想想就太疯狂了，这让我不禁怀疑自己是不是不应该这样写代码。
-->
-->换做其他语言，可能就不能像java这样做到用RuntimeException包装错误然后丢到上层处理了，所以这不是一个广泛适用的办法，更何况这个办法本来就很鸡肋，RuntimeException一般也不是用于这类错误的，它本应该对应的是造成以恐慌模式结束程序或者线程的错误。
-->
总结问题如下：
-->我已经分析了父类方法、接口方法或者trait方法不设计错误返回的签名的危害，现在第一个问题是为什么很多标准库中的接口/特征方法不设计错误返回或者只设计了它感兴趣的错误返回？
-->
-->如果你觉得（标准库）它们这么做是合适的，那么第二个问题就是怎么判断父类方法、接口方法或者trait方法要不要设计让实现方法/子类方法设计返回任何错误的类型的签名，以及怎么处理当实现方法/子类方法确实需要返回超过父类方法、接口方法或者trait方法签名声明的错误范围的情况。

Answer 1

你这文字描述太多，其实就一个重点，或者姑且算是一个讨论议题。
结论：在设计接口或特征方法时，需要判断是否需要设计异常错误返回。
通常情况下，如果接口或特征方法执行过程中可能出现异常或错误，并且该异常或错误会对调用方产生影响，那么就需要设计异常错误返回。例如，在编写一个文件读取方法时，如果文件不存在或无法读取，就需要设计异常错误返回，以便调用方能够捕获并处理该异常。然而，在设计接口或特征方法时，也需要考虑异常错误返回对方法性能的影响。如果异常错误返回过于频繁，可能会影响方法的执行效率。因此，在设计异常错误返回时，需要权衡方法的性能和可靠性。
因此，在设计接口或特征方法时，需要根据方法的实际需求和场景来判断是否需要设计异常错误返回。如果方法执行过程中可能出现异常或错误，并且该异常或错误会对调用方产生影响，那么就需要设计异常错误返回。

Answer 2

只是软件实现和设计的问题，如果第三方库，也好像并没有选择的余地，如果自己写的类库，是否抛出错误也取决于设计，需要清楚表达错误详细信息的或者需要上层补救的建议抛出，如果只是传递执行结果状态就不跑出。纯粹看实现者的意图而定，个人看法，仅供参考。

Answer 3

Java异常处理和设计
可以参考下
https://blog.csdn.net/guanshengg/article/details/126554849

Answer 4

我的观点是:接口方法应该在签名中体现一般的错误处理策略,而由实现方法决定具体的错误类型;文档中应说明实现方法可能抛出的错误信息;不应使用RuntimeException来隐藏错误,这会增加调用者的负担。

Answer 5

不知道你这个问题是否已经解决, 如果还没有解决的话:

• 帮你找了个相似的问题, 你可以看下: https://ask.csdn.net/questions/7608673

如果你已经解决了该问题, 非常希望你能够分享一下解决方案, 写成博客, 将相关链接放在评论区, 以帮助更多的人 ^-^

Answer 6

为什么很多标准库中的接口/特征方法不设计错误返回或者只设计了它感兴趣的错误返回？
这可能是因为标准库中的接口/特征方法通常是通用的、广泛适用的，无法预测具体的实现方式和实现可能出现的错误情况。在这种情况下，为接口/特征方法指定详细的错误返回类型可能会限制具体实现的灵活性。标准库的设计者可能更倾向于将错误处理的责任留给使用者，让使用者在具体的实现中决定如何处理错误。这样可以使接口/特征方法更通用、更灵活，适用于更多的场景。

如何判断父类方法、接口方法或者特征方法是否应该设计错误返回的签名？
这个判断通常基于设计者对于错误处理的预期和具体业务需求。一些考虑因素可能包括：

错误的严重性：如果父类方法、接口方法或者特征方法可能导致严重的错误，那么设计错误返回的签名可能更合适。例如，在涉及到文件操作或者网络通信的方法中，错误可能具有更高的严重性，因此错误返回的签名可能更有必要。

可预测性：如果父类方法、接口方法或者特征方法中的错误是可预测的，并且在实现时可以明确定义和处理，那么设计错误返回的签名可能更有意义。如果错误是不可预测的或者高度依赖于具体实现，那么错误返回的签名可能会限制实现的灵活性。

接口设计的目标：如果接口的设计目标是提供一组通用操作而不涉及具体实现的细节，那么设计错误返回的签名可能会增加接口的复杂性。在这种情况下，将错误处理的责任留给使用者可能更符合接口设计的目标。

处理实现方法/子类方法需要返回超过父类方法、接口方法或者特征方法签名声明的错误范围的情况。
如果实现方法/子类方法需要返回超过父类方法、接口方法或者特征方法签名声明的错误范围，有几种可能的处理方式：

使用异常：可以考虑在实现方法/子类方法中使用异常来处理超出签名声明的错误范围。异常提供了一种灵活的错误处理机制，可以捕获和处理不同类型的错误。

设计更灵活的接口：如果实现方法/子类方法的错误范围超出了父类方法、接口方法或者特征方法的签名，那么可以考虑重新设计接口，使其能够更好地满足具体实现的需求。这可能涉及修改接口的签名或引入更灵活的错误处理机制。

Answer 7

为了简化接口和方法的使用，减少使用难度和复杂度，提高效率和易用性。如果所有的接口和特征方法都要考虑错误返回，那么这些接口和方法会变得更加臃肿和复杂，使用起来也会更加麻烦。因此很多标准接口/特征方法不设计错误返回