2010-08-28 199 views
0

建议在finally块中拥有业务逻辑吗? 工作结束后(无论是否成功),我必须发送电子邮件通知。我可以将电子邮件逻辑放在最终块中吗?我可以在Finally块中拥有业务逻辑吗?

+0

当然,但是当电子邮件失败时会发生什么? – leppie 2010-08-28 05:25:39

+0

@leppie这个案子也是我的想法。那么你在哪里建议放置电子邮件代码? 在另一个笔记上,我已经读过,finally块总是应该用来清理资源。那么保留一些业务逻辑真的是一个不好的习惯吗? – Mayank 2010-08-28 05:32:25

回答

1

我能想到的主要危险是finally块有能力默默吞下异常并从try块本身返回值。

例如,

try { 
    doSomethingFancy(); 
} finally { 
    sendEmail(); 
} 

如果doSomethingFancy抛出一个异常,你会试图发送电子邮件。如果以某种方式发送电子邮件失败,sendEmail可能会抛出异常。这个例外将会“覆盖”原来抛出的一个,你永远不会看到它。它会消失。

你可以解决这个代码防守更try/catch块,但只是知道......

+0

我已经实现了(几次)帮助类,它将运行一系列操作,并在特定操作失败时捕获异常/继续。一旦所有动作都被执行,如果有任何异常被抛出,它们将被汇总为一个主异常,我会抛出异常。 – 2010-08-28 06:01:02

0

你可以做的是,在案件catch块,如果你打算发送错误条件指定的电子邮件ID。 finally块通常主要用于资源的优化释放。我不建议在finally块中发送电子邮件或执行任何业务规则。

1

理想情况下,您应该在Try块中拥有业务逻辑,并且最后块应包含任何清理任务或任何必须发生的事情,而不管try块的成功或失败。您还需要确保finally块中的代码不会导致任何异常,否则在Steven提到的情况下,原始异常将会丢失(如果有)。

0

在我的脑海里,

try { 
    doSomethingFancy(); 
catch(Exception ex) { 
    logError(ex); 
} 
sendMail(); 

是为这个完美的模式。最后,块应该只用于清除try块中的代码可能留下的混乱。

+0

但是,正如Steven指出的那样,如果sendMail抛出一个异常会发生什么?它不会让我的系统崩溃吗? – Mayank 2010-08-28 17:25:22

+0

当然,但是你可以把它放在一个单独的try catch块中。只要有两段代码以不同的方式处理Exception,您当然需要将它们放在单独的try catch块中。 – VdesmedT 2010-08-28 21:46:57