【问题标题】:Classes used to manage exception用于管理异常的类
【发布时间】:2016-01-14 07:57:59
【问题描述】:

有一个用于捕获异常的短方法的类是不是很好?

class ContractUtils{
  public static String getCode(Contract contract) throws MyException{
    try{
      return contract.getInfo().getCode(); //throws ContractException and LogicException
    }catch(Exception e){
      throw new MyException("error during code reading:"+e.getMessage, e);
    }
  }
  //other methods like above...
}

【问题讨论】:

  • 别忘了在你的方法签名中写上“throws”
  • 嗯嗯。一旦您可以有效地响应异常,就应该尽快处理它们。通常,这不会出现在某些随机实用程序方法中,而是更低(在contract.getInfo().getCode() 本身中)或更高(在您可以生成有用错误消息的应用程序级别)。
  • 如果contract.getInfo().getCode() 抛出例如NullPointerException 还是 ArithmeticException?在这些情况下,您肯定不想抓住并抛出MyException 吗?
  • 不,只需将您的 try/catch 直接放在您的真实方法中(您有联系人并想获取它的代码)。最好用 try/catch 包围“contract.getCode()”,而不是使用“getCode(Contract contract)”静态方法。
  • 用例场景是这样的:我正在使用外部参与者给我的 Contract 类,这些类为每个 get 方法抛出两种类型的自定义异常,我的想法是有一个类管理这些异常并将有用的错误消息放入新的自定义异常中。在更高级别,我将捕获每个异常并使用以下模式记录消息:“合同编辑期间出错:”+e.getMessage。所以我期望的结果是这样的:“合约编辑期间出错:代码读取期间出错:值为空”

标签: java methods try-catch short


【解决方案1】:

将应用程序逻辑与错误处理分开以提高可读性会很有用。

但不在实用程序类中,因为您可能忘记使用它,直接完成它的任务,但仍然期望自定义异常。如果经常使用它(并使 Contract.getInfo() 私有),我会将这个逻辑放在 Contact 类中。另一个缺点是,它可能导致实用程序类对其他类的实现细节过于了解(LoD - https://en.wikipedia.org/wiki/Law_of_Demeter),可能会破坏封装并由于更高的依赖性而降低它们的可维护性。

而且,您可能想要捕获特定的异常。

【讨论】:

  • 是的,我同意你的观点,这件事应该在 Contract 类中完成,不幸的是它变成了来自外部参与者并且无法更改它的选项,然后我决定写Contract 类的一种“代理”。
  • 我明白了,你可以用合成来包裹它,如果它不是太大的话。
  • 是的,它也可以是一个很好的解决方案来包装它并覆盖我必须调用的方法,我喜欢它。
【解决方案2】:

您的实用程序类ContractUtil 引入了一个级别的间接,只是为了将原始异常转换为另一个异常:

而不是直接调用:

 return contract.getInfo().getCode()

你现在写的比较人工

 return ContractUtils.getCode(contract);

可能存在这种解决方案合理的情况,例如:

你是 不允许抛出 ContractException 或 LogicException,并且您经常调用此方法 次。

但是如果你可以改变它的签名,最好重新设计原来的方法,只抛出MyException

【讨论】:

  • 它不经常被调用,但我必须多次使用它,所以我想使用一种方法来管理一次异常并总是得到相同的消息错误
  • @user1951947 那么将这个错误消息规范化移动到方法中不是更好吗?正如我所说,如果这不是一个选项,那么您的解决方案对我来说似乎没问题。
【解决方案3】:

如果自定义异常为调用代码提供了额外的上下文或价值,那么创建它们是有用的并鼓励创建它们。

您使用静态方法的方法是完全可以接受的。这是一个很好的 SO answer 定义短静态方法的用例。

【讨论】:

    【解决方案4】:

    在代码中单独捕获和处理异常总是更好的。不建议分配常见的自定义异常。

    有关管理异常的最佳做法,请参阅此链接:

    https://softwareengineering.stackexchange.com/questions/209693/best-practices-to-create-error-codes-pattern-for-an-enterprise-project-in-c

    【讨论】:

    • OP 从未说明这些异常的管理程度。几乎每个 COTS 和 OSS 库都会创建自定义异常。此外,您链接到的答案被 SO 用户社区发现过于宽泛。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-01-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多