Cannot Transfer request to Desired ASP.NET Error Page - asp.net

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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?