编程风格：尝试捕捉和外部依赖

Question

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

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

if (transaction_successful)
   send_message;

如果事务成功，我可以考虑测试的唯一方法是在try catch块中设置方法变量标志，然后在if语句中测试它。当然这可行，但我很想知道传统的“智慧”是什么呢？也许“send_message”应该在try catch块中，尽管这可能是不必要的混乱？我想这是一个相当直接的问题 - 只是试图确保我的代码结构良好/有条理。

Answer 1

您似乎需要多考虑一下软件的正确分层/增加此类/方法的内聚力。 从提供的示例看来，在这里你有DAL /业务层混合（persistense +一些业务活动），这是你需要在catch块后面的同一方法中对事务结果做出反应的主要原因。

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

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

当然你可以设置标志（如你所建议的）并使用AOP建议处理这种情况（特别是如果'send_message'是辅助功能）。

Answer 2

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

Answer 3

假设（虽然从你的代码中看起来非常明显）你正试图发送一条消息，当且仅当交易成功时，我认为把它作为一部分是有意义的尝试块本身。

在我看来，它不会是“不必要的混乱”，因为消息需要在成功时发送。如果消息包含要发送的部分，即使事务失败，那么保持标记并跟踪事务状态（并相应地修改消息）显然是有意义的。

Answer 4

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