ASP.NET error handling with more than one AJAX control

Brief:

I have a problem where when performing an action on an ASPX page an exception is thrown twice.

Details:

I have two ASP.NET Controls (Intersoft Webgrids). These controls are bound to two different datasets and when I press the "run" button grid #1 is updated which then automatically cascades and updates (or clears) grid #2 at the same time. The two grids are updated using Intersoft's "FlyPostback" AJAX which seems to be quite similar to ASP.NET AJAX Update Panels i.e. the whole ASP.NET life-cycle goes on (Page_Load and all that).

All of my pages inherit from a base page which overrides OnError. OnError will then log the error, clear the error and redirect to an error page. The error page shows a nicely formatted snippet of the exception details.

My OnError method looks something like this

Session["lastError"] = Server.GetLastError();
Server.ClearError();//Have tried with and without this
this.ErrorPage = "ErrorPage.aspx";
Response.Redirect(this.ErrorPage, true);

Problem:

When an exception occurs after pressing the "run" button I seem to get redirected to the error page twice. The first time I am redirected I can see (via the debugger) that I am getting the 开发者_如何学Pythoncorrect exception on the error page, but then I get redirected again to the error page and this time I have no exception details. I do not observe this problem with just one webgrid. It seems to me like the second grid also tries to handle the exception, but the first grid has already handled and cleared it.

UPDATE: It seems like OnError is only being called once, but the error page is loading twice.

Question:

Is there an obvious error here? Is there a better way to handle this situation? The first grid should handle the exception and abort all other requests (or at least let them do their thing without bothering me), but of course grid #1 doesn't know if grid #2 is/was updating.

---

I'm pretty sure that using Response.Redirect throws a ThreadAbortException by design:

http://support.microsoft.com/kb/312629

However, a catch block that looks similar to this will also cause a problem, if you have it:

catch (Exception ex)
{
   // log or something
   throw ex;
}

That behaviour will remove the exception details as it masks the original exception.

However, it's more likely, its the .Redirect behaviour here though.