3

我有一个简单的风格问题。在我正在编写的应用程序中，有几个类方法包括 try/catch 块以及取决于块结果的块外部函数。例如（在伪代码中）：

try {
   start_transaction;
   persist_data;
   stop_transaction;
}
catch {
   rollback_transaction;
}
finally {
}

if (transaction_successful)
   send_message;

我能想到的测试事务是否成功的唯一方法是在 try catch 块中设置一个方法变量标志，然后在 if 语句中对其进行测试。当然这会起作用，但是我很想知道传统的“智慧”是什么？也许“send_message”应该在try catch块中，尽管这可能是不必要的混乱？我想这是一个相当直截了当的问题 - 只是试图确保我的代码结构良好/组织良好。

4

4 回答 4

4

看来您需要更多地考虑软件的正确分层/增加此类/方法的凝聚力。从提供的示例看来，这里您有 DAL/业务层组合（持久性 + 一些业务活动），这是您需要在 catch 块之后以相同方法对事务结果做出反应的主要原因。

通过适当的分层，它可能如下所示：

  • 持久性失败，您通过向调用层抛出检查/运行时异常来指示这一事实（由您决定如何准确指示失败，取决于您的架构方法），
  • 调用类捕获异常并进行错误处理 - 或在调用“持久”方法之后立即在相应的尝试块中发送消息

当然，您可以设置标志（如您所建议的那样）并使用 AOP 建议来处理这种情况（尤其是如果'send_message'是辅助功能）。

于 2012-07-12T02:30:12.657 回答
1

try将它放在块中会很简单。“杂乱的代码”是个人喜好的问题，但这使事情变得简单。

于 2012-07-12T02:19:44.620 回答
1

假设（尽管这在您的代码中看起来很明显）当且仅当事务成功时您才尝试发送消息，我认为将其作为 try 块本身的一部分是有意义的。

在我看来，这不会是“不必要的混乱”，因为消息需要在成功时发送。如果即使交易失败，消息也有部分要发送，那么保留标志并跟踪交易状态显然是有意义的（并相应地修改您的消息）

于 2012-07-12T02:22:30.447 回答
1

将它放在try块内，但万一在执行时抛出异常send_message，最好有自己的catch块 - 这是通过指定适当的异常类来完成的。

于 2012-07-12T02:22:56.387 回答