嵌套的Try/Catch
使用嵌套的Try/Catch是不是编码不干净的信号？我想知道是不是因为在catch中我调用了另一个方法，如果调用失败，我会得到另一个运行时错误，所以我很想再次使用try/catch将这些调用包装在catch中。我想知道这样做是否正常？
例如：
catch (Exception ex)
{
transaction.VoidOrder(transactionID);
LogError(ex.ToString());
Response.Redirect("Checkout", false);
}因此，VoidOrder甚至LogError方法可能会崩溃。现在，当我调用VoidOrder时，我在transactionID上得到了一个空引用，因为它调用了BL方法，在BL方法中，我重新抛出了它，这样我就可以在上面代码的更高级别捕获它。但是如果我在接球内再次投球，那么我也需要接球。
回答 5
Stack Overflow用户
发布于 2010-02-23 04:00:31
下面是我们解决这个问题的方法：
从UI/ catch后台级别到其他层的所有调用都使用try-catch，其中我们总是捕获自定义异常。底层采取的所有操作都有自己的try-catch，用于记录、包装和抛出自定义异常。然后，UI可以依赖于此，并查找具有友好错误消息的已处理异常。
代码背后：
protected void btnSubmit_Click(object sender, EventArgs e)
{
//do something when a button is clicked...
try
{
MyBL.TakeAction()
}
catch(MyApplicationCustomException ex)
{
//display something to the user, etc.
ltlErrorPane.Text = ex.Message;
//or redirect if desired
if(ex.ErrorType == MyCustomErrorsType.Transactional)
{
Response.Redirect("~/Errors/Transaction.aspx");
}
}
}BL:
在业务层中，任何可能失败的操作都会使用try-catch，它会在将问题抛到UI之前记录并包装问题。
public class MyBL
{
public static void TakeAction()
{
try
{
//do something
}
catch(SpecificDotNetException ex)
{
//log, wrap and throw
MyExceptionManagement.LogException(ex)
throw new MyApplicationCustomException(ex, "Some friendly error message", MyCustomErrorsType.Transactional);
}
finally
{
//clean up...
}
}
}异常处理程序：
实际的异常处理程序有多种方式来记录日志，包括事件日志、文件日志，如果所有其他方法都失败了，最后还会发送电子邮件。如果记录器不能执行任何预期的操作，我们选择简单地返回false。不过，这是我个人的选择。我们认为3种方法连续失败的可能性很小(事件日志失败，尝试文件日志失败，尝试电子邮件失败，失败)。在这种情况下，我们选择允许应用程序继续运行。你的另一个选择是让应用程序完全失败。
public static class MyExceptionManagement
{
public static bool LogException(Exception ex)
{
try
{
//try logging to a log source by priority,
//if it fails with all sources, return false as a last resort
//we choose not to let logging issues interfere with user experience
//if logging worked
return true;
}
catch(Exception ex)
{
//in most cases, using try-catch as a true-false is bad practice
//but when logging an exception causes an exception itself, we do
//use this as a well-considered choice.
return false;
}
}
}最后，为了安全起见，我们实现了Application_Error全局事件处理程序(在Global.asax中)。对于我们没有正确尝试捕获的情况，这是最后的手段。我们通常记录并重定向到一个友好的错误页面。但是，如果上述自定义错误处理成功完成，则很少有错误会到达全局处理程序。
希望这能帮上点忙。这是一种可能的解决方案。几年来，它在一些较大的应用程序上运行得很好。
Stack Overflow用户
发布于 2010-02-23 04:20:46
在需要以其他重要方式记录、发送消息或对异常做出反应的顶级应用程序中，嵌套的try/catch块是不可避免的。
有一些方法可以减少嵌套块的数量(例如，使用ASP.Net的HttpApplication.Error处理程序合并错误处理(也称为.Application_Error))，但是您应该捕获处理代码产生的任何异常，并实现一个备份计划，以防所有其他方法都失败。
Stack Overflow用户
发布于 2010-02-23 04:24:13
嵌套问题的另一个解决方案是将内部函数(LogError等)的try/catch逻辑封装在这些函数中，而不是依赖调用者来捕获它们。对于LogError来说，这是有意义的，因为无论是谁在尝试记录错误，您都可能希望以相同的方式处理损坏的错误记录器。
https://stackoverflow.com/questions/2313696
复制相似问题
腾讯云开发者
