如果有一个嵌套的Try/Catch，这是否意味着你的代码不够简洁？我在想这个问题，因为在我的catch中，我调用了另一个方法，如果该方法失败，我会得到另一个运行时错误，所以我想用另一个try/catch来包装这些调用。我想知道这样做是否正常？
例如：
catch (Exception ex)
{
transaction.VoidOrder(transactionID);
LogError(ex.ToString());
Response.Redirect("Checkout", false);
}
因此，VoidOrder甚至LogError方法可能会崩溃。现在，当我调用VoidOrder时，由于它调用了一个BL方法并且在该BL方法中重新抛出异常，因此我会在transactionID上获得null引用，在上面的代码中，我可以捕获它。但是，如果在catch块内再次抛出异常，则我需要捕获它。
我们处理这个问题的方法如下：
UI / codebehind 层级中通往其他层级的所有调用都使用 try-catch，其中我们始终捕获自定义异常。底层执行的所有操作都有自己的 try-catch，会记录、包装并抛出自定义异常。然后 UI 可以依赖此功能，并寻找带有友好错误消息的已处理异常。
Codebehind:
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");
}
}
}
业务层：
在业务层中，任何可能失败的操作都会使用try-catch块进行处理，该块会在将问题抛到用户界面之前记录并封装问题。
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。尽管这是个人选择，但我们认为三种方法依次失败的可能性非常小（事件日志失败，尝试文件日志，失败，尝试电子邮件，失败）。在这种情况下，我们选择允许应用程序继续运行。另一个选项是允许应用程序完全失败。
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;
}
}
}
最后，作为一种应急措施，我们还在Global.asax中实现了Application_Error全局事件处理程序。当我们没有正确地try-catch某些内容时，这是最后的手段。一般情况下，我们会记录并重定向到友好的错误页面。如果以上自定义错误处理成功完成，很少有错误会到达全局处理程序。
希望这可能对您有所帮助。这是一个可能的解决方案。在一些较大的应用程序上，它已经成功运行了几年。
HttpContext.Current.Response.Redirect进行重定向，那么可以这样做。您可以像我的示例代码一样在BL中记录，然后重定向。个人而言，我宁愿让UI做出UI决策，而BL只是告诉UI问题所在。在我看来，保持事物分割更好。BL应处理业务决策（事务、验证、保存、获取等），而不知道UI的情况。理想情况下，您应该能够在不重构BL的情况下将UI切换到Windows窗体。当BL调用HttpContext.Current.Response.Redirect时，您无法执行此操作。 - KP.嵌套的try/catch块在需要记录日志、发送消息或以其他非平凡方式响应异常的顶级应用程序中是不可避免的。
有一些方法可以减少嵌套块的数量（例如，使用ASP.NET的HttpApplication.Error处理程序（又称Application_Error）来 consololidate 错误处理），但您应该捕获由处理代码产生的任何异常，并在万不得已时实施备份计划。
解决嵌套问题的另一个方法是在内部函数（LogError等）中封装try/catch逻辑，而不是依赖调用者来捕获它们。对于LogError来说，这是有意义的，因为您可能希望以相同的方式处理破损的错误记录器，无论谁试图记录错误。
也许有人会问为什么要使用嵌套的try/catch语句。有时候不得不使用它们，但我认为通常情况下并不美观。
你应该考虑到关注点分离是必须的。
一个getControl方法不应该插入脚本，一个save方法也不应该做更多的事情除了保存。
检查这些方法确切应该做什么，然后你就会得到答案。如果出现错误将订单设置为空看起来并不奇怪。听起来很合理。