8
最终尝试使用（无捕获）vs枚举状态验证
我一直在阅读有关此问题的建议，即应如何在尽可能接近引发异常的地方处理异常。 我对最佳做法的两难选择是，是否应该使用try / catch / finally返回一个枚举（或一个表示值的int，0表示错误，1表示ok，2表示警告等，视情况而定），以便一个答案总是有序的，还是应该让异常通过，以便调用方可以处理它？ 据我所知，根据具体情况，这可能会有所不同，因此最初的建议似乎很奇怪。 例如，在Web服务上，您总是希望返回一个状态，因此必须当场处理任何异常，但是可以说在通过http发布/获取某些数据的函数中，您希望例外（例如404情形）传递给触发它的人。如果不这样做，则必须创建某种方式来告知调用方结果的质量（错误：404）以及结果本身。 尽管可以在获取/发布数据的帮助程序函数中尝试捕获404异常，但是应该吗？难道只有我一个人使用smallint表示程序中的状态（并适当地记录它们），然后将此信息用于外部的健全性验证（一切正常/错误处理）吗？ 更新：我期待主要分类出现致命/非致命的异常，但是我不想包括该异常，以免影响答案。让我澄清一下问题所在：处理引发的异常，而不是引发异常。预期的效果是：检测到错误，然后尝试从中恢复。如果无法恢复，请提供最有意义的反馈。 同样，对于http get / post示例，问题是，是否应该提供一个新对象来描述原始调用者发生了什么？如果此帮助程序在您正在使用的库中，您是否希望它为您提供操作的状态代码，还是将其包含在try-catch块中？如果您正在设计它，您是否会提供状态代码或引发异常，然后让上级将其转换为状态代码/消息？ 简介：您如何选择一段代码而不是产生异常，而是返回状态代码以及可能产生的任何结果？