Server.Transfer和System.Threading.ThreadAbortException [英] Server.Transfer and System.Threading.ThreadAbortException

问题描述

请参阅 http://support.microsoft.com/kb/312629/EN -US /

我也在我的应用程序中使用reponse.direct，我没有得到异常。知识库文章建议（Server.Execute）的解决方法对我来说不起作用。如果我使用Server.Execute，我在目标页面上从Ajax Toolkit获取了大量的JavaScript异常，我没有深入了解原因。

I am using reponse.direct in my app as well and I am not getting the exception. The workaround that the knowledge base article suggests (Server.Execute) does not work for me. I am getting lots of javascript exceptions from the Ajax Toolkit on the target page if I use Server.Execute, and I did not dig into the cause.

我的问题 - 什么你会看到反对只是将异常吞噬为已知限制并继续前进吗？

My question - what arguments do you see against just swallowing the exception as a 'known limitation' and moving on?

我在这个非常具体的案例中使用Server.Transfer的原因是我想要屏蔽正在执行的页面的（实际）目标网址。它的作用很好，除了这个异常（用户从未看到）。

My reason for using Server.Transfer in this one very specific case is that I want to mask the (real) target url of the page that is actually executing. It works pretty well, except for this exception (that the user never sees).

推荐答案

确保您没有调用服务器。 Transfer（）在一个异常处理程序（try..catch / finally）中。

Make sure you are not calling Server.Transfer() within an exception handler (try..catch/finally).

编辑：

Server.Transfer在完成后总是引发ThreadAbortException。如果你把它包装在一个异常处理程序中，你应该捕获显式的异常类型而不是'Exception'。

Server.Transfer always raises ThreadAbortException upon completion. If you wrap it in an exception handler you should trap for explicit exception types instead of just 'Exception'.

请参阅 MSDN 。以下是有关 ThreadAbortException

这篇关于Server.Transfer和System.Threading.ThreadAbortException的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！