无法将请求传输到所需的 ASP.NET 错误页面
在 Page_Load() 部分中，我检查有效的输入& 如果它们无效，我会将请求转移到自定义错误页面。
这样做时，会引发 ThreadAbortException，该异常被我的 catch 块捕获，但 ASP.NET 将请求传输到未知异常页面。 我究竟做错了什么？ 我不希望当我转移到错误页面时出现 ThreadAbortException。 例如：
protected void Page_Load(object sender, EventArgs e)
{
try
{
if (String.IsNullOrEmpty(szProductName))
{
//Product name not given. Hence cant process further.
Server.Transfer(Constants.ERROR_WRONG_INPUTS_ASPX);
}
else
{
//Do something.....
}
}
catch(Exception Ex)
{
}
}
作为一种解决方法，我现在使用：
Response.Redirect(Constants.ERROR_WRONG_INPUTS_ASPX, false);
而不是 Server.Transfer 即我允许该过程在后台继续，这使得我需要检查有效性和有效性。 然后只执行剩余的代码。
我的问题类似于： 异常处理应用程序块在 ASP.NET 中运行的异常处理程序无法调用 Response.End()，但似乎没有得到答复。
In the Page_Load() section, I check for valid inputs & incase they are invalid, I transfer the request to a custom error page.
While doing so, a ThreadAbortException is thrown which is caught by my catch block but asp.net transfers the request to unknown exception page.
What am I doing wrong? I dont want the ThreadAbortException to come when I transfer to the error page.
eg:
protected void Page_Load(object sender, EventArgs e)
{
try
{
if (String.IsNullOrEmpty(szProductName))
{
//Product name not given. Hence cant process further.
Server.Transfer(Constants.ERROR_WRONG_INPUTS_ASPX);
}
else
{
//Do something.....
}
}
catch(Exception Ex)
{
}
}
As a workaround, I now use:
Response.Redirect(Constants.ERROR_WRONG_INPUTS_ASPX, false);
instead of Server.Transfer i.e. I allow the process to continue in the background which made required I check for validity & then only executed the remaining code.
My problem is similar to : Exception Handling Application Block Exception Handler running in ASP.NET cannot call Response.End() but it seems it was not answered.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Response.Redirect 抛出 ThreadAbortException 以中止当前页面并将控制权转移到新页面。 添加 false 参数“修复”了这个问题，因为它告诉 Response.Redirect 在转移控制之前完成当前页面的处理。
我相信你需要看看你的申请流程。 对我来说，由于输入错误而将页面转移到错误页面似乎是一种过于复杂的处理输入验证的方法。 我认为您最好使用显示消息的回发，或者在发布页面之前在 javascript 中进行一些验证。
Response.Redirect throws the ThreadAbortException to abort the current page and transfer control to the new page. Adding the false parameter "fixed" this problem because it tells Response.Redirect to complete processing on the current page before transfering control.
I believe though you need to look at your application flow. Having a page transfer to an error page because of input errors seems like an overly complicated way to handle input validation to me. I think you are better off with a postback that displays messages, or doing some validation in javascript before the page is posted.
任何时候调用 Response.End() 时，都会发生 ThreadAbortException。 Server.Transfer 在内部调用 Response.End()，因为它立即结束当前处理并将请求移交给新页面，新页面负责将信息返回到浏览器。
Response.Redirect 更加优雅，因为它完成当前请求的处理并向客户端返回 301 Redirect 响应。 通常，这会导致浏览器向服务器发出第二次请求以请求重定向 URL。
你说它正在转移到未知的错误页面，但我不确定为什么。 您是否在 Global.asax 的 Application_Error 方法中执行此操作？ 如果错误得到处理，您应该能够控制它的去向。
Any time that Response.End() is called, a ThreadAbortException will occur. Server.Transfer calls Response.End() internally because it immediately ends the current processing and hands off the request to the new page, which becomes responsible for returning information to the browser.
Response.Redirect is more graceful, as it finishes processing the current request and returns a 301 Redirect response to the client. Generally this causes the browser to do a second request to the server to request the redirect URL.
You say it's transferring to an unknown error page, but I'm not sure why. Are you doing so in your Application_Error method in Global.asax? If the error is handled you should be able to control where it's heading off to.
我建议你摆脱那个 try...catch 块。 你期待在那里抓到什么？ 如果您确实期望出现一些取决于您的实现的特殊情况，那么这种情况会在您的 else 块内进一步发生。 所以你应该用 try...finally 来包装它。
ASP.NET 在结束请求时抛出 ThreadAbortException，但它最终会在调用堆栈的上部捕获它，因此您不应该自己捕获它。 如果您期望其他一些可能的状态损坏，只需让它传播到全局异常处理程序即可； 抛出的不是您的代码。
I sugest you get rid of that try...catch block. What are you expecting to catch out there? If you really expect some exceptional situation that depends on your implementation, that would happen further down inside your else block. So you should wrap it with try...finally there.
ASP.NET throws the ThreadAbortException when ending your request but it catches it eventually upper in the call stack so you should not catch that yourself. If you're expecting some other possible state corruption just let it propagate up to the global exception handler; it's not your code that throws.
如果产品丢失或者该产品不在您的数据存储中，那么您可能需要考虑返回 404（未找到页面）。 这向浏览器（以及谷歌搜索蜘蛛！）表明不存在这样的页面。 您是否计划使用 SEO 友好的 URL，例如：
http://MyServer/MySite/Products/FireFox？
If a product is missing or if the product isn't in your data store then you might want to consider returning a 404 (Page Not Found). This indicates to the browser - (and to google search spiders!) - that there isn't such a page. Are you planning on using SEO friendly URLS such as:
http://MyServer/MySite/Products/FireFox?