ASP.NET MVC2 - try/catch（throw？）块的数量和位置

我正在通过整个异常处理丛林进行颠簸，我现在试图确定有多少try/catch我需要的块，以及放置它们的位置。ASP.NET MVC2 - try/catch（throw？）块的数量和位置

从我的控制器我有

CreateInvitation(fromUser, toUser);

其中要求到我的BLL方法

public static Invitation CreateInvitaton(User fromUser, User toUser) 
{ 
    try 
    {// see if toUser exists, then create the invitation} 
    catch 
    {// throw something, maybe?} 
}

我是不是真的需要这个方法重新把它扔？即使我不重新扔掉它，它会不会回到堆栈？

我是否还需要将控制器的调用包装在try/catch块中，或者是多余的？

也许我根本不需要BLL方法中的try/catch块，只需要我的控制器中的try/catch块？

我正在看这里的不少可能的组合，不知道什么是正确的。

谢谢。

来源

2010-09-15 asfsadf

捕获例外当地当且仅当它们指示特殊行为和可以是固定的（或评论）在本地。

很难找到一个例子 - 这里是一个：我有一些物体需要悲观锁。锁定是因为从Web应用程序写入对象，而另一个（背景）应用程序正在读取它可能会导致灾难。这确实是一个例外，因为它很少会发生。此外，我事先不做任何事情（因为锁可能是在下一行执行之前获得的）。不过，我可以重试几次，因为我知道再次发布对象的机会很大。尽管如此，所有这些都不是在控制器中发生的，而是在服务类中。

不要对预期条件使用异常（例如，无效输入）。

此外，我同意web应用程序中的大多数例外都无法处理，除了记录一条消息（应该在控制器中执行而不是）并发送一个错误页面。最后，在捕捉异常时，确保正确执行此操作（捕获特定的异常类型，使用throw;而不是throw ex;）

来源

2010-09-15 18:09:15 mnemosyn

那么没有理由在控制器中有任何try/catch块，呃？ – asfsadf 2010-09-15 18:14:42

在您的示例中编写的异常处理程序完全没有任何功能。（嗯，这是浪费时间的一点点，但它什么都不做使用）

如果当时：然后将需要

try 
{...} 
catch 
{ 
    // do something here. 
    throw; 
}

的try/catch语句&抛出。

来源

2010-09-15 17:37:13

+1。在此扩展：除非需要添加对异常消息有意义的内容，否则不要使用try/catch。 99％的时间您应该允许异常一直到您的默认错误页面并将其记录到ELMAH之类的内容中。 – 2010-09-15 17:41:46

谢谢。我只是使用该shell作为更多的占位符来表明我正在考虑将它放在哪里。 – asfsadf 2010-09-15 17:42:49

好吧，让BLL try/catch模块消失，并查看我的控制器中的任何错误？ – asfsadf 2010-09-15 17:43:55

ASP.NET MVC2 - try/catch（throw？）块的数量和位置

回答

相关问题