UpdatePanel: having fun with errors
UpdatePanel has always given us some sort of error handling during partial postbacks (or, if you want to use the new official term, async postbacks). In previous CTPs, you could handle a page error event and perform your own error handling (which normally consisted in some form of logging). The problem previous versions had was related with the way that the error message was shown in the client side (by default, it showed an alert message box, though you could define a limited error template). The current release give us a lot more options as I'll show you in this post.
If you don't do anything, when you get an error during partial postback you'll get a simple alert message box showing you the error message associated with the exception you had in the server. As we all agree, this is not the best info to show to our users; it's also not a good idea to show a standard error message. If we don't mind showing an alert message in the client, then we can start by handling the AsyncPostBackError event generated by the ScriptManager control in order to customize the error message returned from the server. Here's a simple page that shows this approach:
<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<script runat="server">
void handleClick(object sender, EventArgs e)
{
int a = 0;
int res = 10 / a;
}
void HandleError(object sender, AsyncPostBackErrorEventArgs e)
{
//here we could log the error, and see which exception we're getting in order to set a specific error message
//in this case, I'm just returning the current date/hour back
manager.AsyncPostBackErrorMessage = "Ooops...error occurred: " +
DateTime.Now.ToString();
}
</script>
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Untitled Page</title>
</head>
<body>
<form id="form1" runat="server">
<asp:ScriptManager runat="server" ID="manager"
OnAsyncPostBackError="HandleError">
</asp:ScriptManager>
<asp:UpdatePanel runat="server" ID="panel">
<ContentTemplate>
<asp:Button runat="server" ID="bt" Text="gerar erro no servidor"
OnClick="handleClick" />
</ContentTemplate>
</asp:UpdatePanel>
</form>
</body>
</html>
As you can see, when the user clicks the button, he'll get a divide by zero exception error on the server side. The previous page shows how you could log the error and return a friendly error message back to the client (the AsyncPostBackErrorMessage was introduced in this version and lets us define the error message which is returned to the client when an exception occurs on the server side). If you run the page, you'll notice that you'll still get the alert message, but this time, it'll show our fridendly error message.
If you want, you can drop the standard alert message and show the error in any way you see fit. To illustrate the steps necessary to perform this operation, I'll start by adding a DIV ccontrol that will be used as a place holder for showing the error returned from the server:
<div id="err"></div>
The next thing we need to do is to handle the endRequest event which is fired by the PageRequestManager object which is present in all the pages that use UpdatePanels:
<script type="text/javascript">
Sys.WebForms.PageRequestManager.getInstance().add_endRequest( endRequest );
function endRequest( sender, e ) {
if( e.get_error() ){
document.getElementById("err").innerText = e.get_error().description;
e.set_errorHandled( true );
}
}
</script>
I start by adding a method that will handle the endRequest event by using the add_endRequest method over the Sys.WebForms.PageRequestManager global object. The method starts by checking if there's an error (by using the get_error method) and, when it finds one, it gets its description (through the description field) and sets the errorHandled field of the EventArgs object used to true so that the default alert message isn't shown to the user. Though the previous code is really simple, there's nothing preventing you from using the toolkit behaviors to get similar results to the ones that we had in the previous CTPS (btw, you can also stop processing the server side error event if you don't need logging and do everything in the client side: you're the one that need to decide on what's best here!).
For those that want to show a default error page, then there's still one additional property exposed by ScriptManager which you'll like: AllowCustomerErrors. When you set this property to true, you're saying that ScriptManager should check for a custom error page associated with the current error an show it to the user. To illustrate its usage, lets start by adding the following to the web.config file:
<customErrors mode="On">
<error statusCode="404" redirect ="error.aspx"/>
</customErrors>
And now lets run the following page:
<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<script runat="server">
void HandleClick(object sender, EventArgs e)
{
this.Server.Transfer("nopage.aspx"); //don't do this in reall AJAX pages!!!!!
}
</script>
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Untitled Page</title>
</head>
<body>
<form id="form1" runat="server">
<asp:ScriptManager runat="server" ID="manager"
AllowCustomErrors="true" />
<asp:UpdatePanel runat="server" ID="panel">
<ContentTemplate>
<asp:Button runat="server" id="bt" Text="postback"
onclick="HandleClick" />
</ContentTemplate>
</asp:UpdatePanel>
</form>
</body>
</html>
First, you should note that you should never use a Server.Transfer instruction on an ajax page. I'm using it since it's simplest way I could think of getting a known 404 error. Now, back to the important things: the AllowCustoErrors property. Since i've set it to true, when ScriptManager handles an exception during an async postback, it'll read the config file and see if there's any error page associated with the current error. If there is, it'll just send an AJAX message to client which instructs the browser to redirect the user to the desired page.
As you have seen, there's now a lot more control over the way exceptions are handled during a partial postback request. You do have to write more code than in the previous versions, but it's also true that the current release is a lot more flexible than the previous one.