【问题标题】:Duplicate in exception handling异常处理中的重复
【发布时间】:2020-05-20 02:45:57
【问题描述】:

我有两个 API(比如 createupdate)调用相同的 serviceAserviceA 有一个条件块,只有在 update 的情况下才会被调用。 serviceA 抛出许多不同的异常,但其中一些只会在 update 调用的条件块内抛出这里推荐的做法是什么?我不希望有重复的异常处理逻辑,但如果我提取错误处理逻辑,我可能必须捕获仅适用于update 的异常create

public class ServiceA {
    void upsert(Request request) {
    //some common operations for create and update
    if (request.action == "UPDATE") {
        //update
        if (someUpdateErrorCondition) {
            throw new ExceptionA();
        } elseif (someOtherUpdateErrorCondition) {
            throw new ExceptionB();
        }
        ...
    }
    if (someErrorCondition) {
        throw new ExceptionC();
    } elseif (someOtherErrorCondition) {
        throw new ExceptionD();
    }
    ...
}

感谢您的帮助!

【问题讨论】:

  • 请提供一些代码!
  • 您所描述的是(许多)原​​因之一,为什么我认为调用 serviceA 然后让 serviceA 测试某种标志以确定它是否在做这根本不是一个好主意创建或更新。为什么不让创建和更新使用不同的服务;如果这些不同的服务具有它们都需要的逻辑块,则调用它;我认为这比在一个逻辑块中创建和更新并通过测试来确定要执行哪些逻辑块更可取。它解决了您的问题,他们可以只创建和声明他们需要的那些异常。
  • @arcy 我同意你在 serviceA 中分离创建和更新的观点,但我觉得异常处理中的重复仍然存在,因为 createupdate api 仍然有常见的异常需要处理。我怎样才能避免这种重复?
  • 我不知道如何在摘要中回答这个问题。我们必须深入了解细节。我愿意这样做,尽管 SO 问题的 cmets 不是一个好方法。

标签: java exception refactoring


【解决方案1】:

不确定我是否正确理解了这个问题,但如果您有要处理的常见异常以及特定异常,那么您可以使用 lambda 进行常见错误处理。 相同的方法有多种风格,即使用共享组件控制执行,无论您使用函数组合、装饰器模式等。

例如(非java伪代码)

function process1() {
  withCommonErrorHandling(() => {
    try { 
        //could throw CommonError or Process1Error
    } catch (Process1Error e) {
        //handle
    }

  });
}

function process2() {
  withCommonErrorHandling(() => {
    try { 
        //could throw CommonError or Process2Error

    } catch (Process2Error e) {
        //handle
    }

  });
}

function withCommonErrorHandling(fn) {
  try { fn() }
  catch (CommonError e) {
      //handle
  }
}

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2014-01-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-04-27
    • 2021-04-13
    • 2018-10-16
    相关资源
    最近更新 更多