views:

405

answers:

6

Was wondering what you thought of this solution, if this is right way to pass an error message to a custom page?

In web.config:

    <customErrors mode="On" defaultRedirect="~/Error.aspx"></customErrors>

In Global.asax:

<script RunAt="server">
    void Application_Error(object sender, EventArgs e)
    {
 Exception ex = Server.GetLastError();
    if (ex != null && Session != null)
    {
        ex.Data.Add("ErrorTime", DateTime.Now);
        ex.Data.Add("ErrorSession", Session.SessionID);
        HttpContext.Current.Cache["LastError"] = ex;
    }
    }

</script>

In my Error.aspx.cs:

protected void Page_Load(object sender, EventArgs e)
{
    if (IsPostBack) return;

    if (HttpContext.Current.Cache["LastError"] != null)
    {
        Exception ex = (Exception)HttpContext.Current.Cache["LastError"];
        if (ex.Data["ErrorTime"] != null && ex.Data["ErrorSession"] != null)
            if ((DateTime)ex.Data["ErrorTime"] > DateTime.Now.AddSeconds(-30d) && ex.Data["ErrorSession"].ToString() == Session.SessionID)
                Label1.Text = ex.InnerException.Message;
    }
}

Of issue: I don't want to do a Server.Transfer from Global.asax because.. I don't know. Seemed clumsy to me. Want to be able to change customErrors to RemoteOnly. So have to save last exception somewhere, but can't be Session, so save to Cache but with some extra data (time and SessionID) since Cache is global and want to make sure not showing wrong error to someone.

+1  A: 

As cache is global this wouldn't be advisable, as you've said you could be displaying the wrong error to someone. I should also say that you shouldn't output the error message directly to end users for security reasons.

Have a look at this issue:

ASP.NET custom error page server GetLastError is null

To summarise put something like the following:

Server.Transfer(String.Concat("~/Error.aspx?message=", HttpUtility.UrlEncode(ex.InnerException.Message)))

Rather than relying on ASP.NET to do the redirect using the settings in the CustomErrors section.

Steve Temple
+1 - I agree that you shouldn't show the error to the user. We log it in the database as I describe in my answer.
Mark Brittingham
+1  A: 

We do something that may or may not work for you. We do extensive logging in the DB. When we get an error, we log it and that produces an error ID. We redirect to the generic page with the error ID and get the details there.

of course this falls flat on its face when the error is 'cannot connect to DB' but that doesn't happen too often ;)

n8wrl
+1 From me - my answer is a bit different but we use DB logging as well so I upvoted you.
Mark Brittingham
+1  A: 

I think that's a decent way to do it. It's not the way I do it, but my code is too lengthy to post (and in VB.NET).

One thing I would change is the error page itself. Instead of displaying the error, consider adding a textbox to the error page as an optional field where the user can enter their email address and click a button to send the error report to you. Then when you receive the error report you can look at the problem and reply to them. It's a much more user friendly way to do it and it's worked out quite well for the sites I've done this on.

Along those lines, you might also want to gather form data, session data, and anything else of value and put that into the error report as well. This can make diagnosing problems much easier.

Steve Wortham
+1 Good answer - I like the idea of giving the user a bit of room to send an email. We can't really do that due to the size of our user base but we do log everything in a db.
Mark Brittingham
Thanks, it's worked out well for us. On our biggest site, we've had 50,000+ users complete our 15-20 page online application. And what I've found about this technique is that it creates a sense of urgency due to the user's expectation and my own. It has a way of motivating me to eliminate all bugs. And once I do that, I spend far less time supporting the website and more time improving it.
Steve Wortham
Just to expand on that, I cannot stress enough how important good error reporting is. It really helps when you receive lots of details that put the error in context. For example, if you iterate through every form key/value pair and include that in the error report, then you know what the user had entered in the form.
Steve Wortham
+1  A: 

I would have to agree with both n8wrl and Steve that a better approach would be to log errors in the database and then return just an Error ID to the user. They really don't need to see the technical details and it is possible that this will expose sensitive information.

In our case, we also pass in the user's ID (if available) and the page where the error occurred (Request.URL is still good when you get to the global Application_Error). This way, we can track down the error a bit easier. Note also that you don't have to use Global.asax with a script tag. If you create a Global.asax.cs file in your App_Code directory, you can just code your C# directly (this may depend on the project type, though).

Mark Brittingham
A: 

I changed my code somewhat. Now it's just:

void Application_Error(object sender, EventArgs e)
{
    HttpContext.Current.Cache["LastError"] = Server.GetLastError().GetBaseException();
    Server.ClearError();
}

...and...

protected void Page_Load(object sender, EventArgs e)
{
    if (IsPostBack) return;

    if (HttpContext.Current.Cache["LastError"] != null)
    {
        Exception ex = (Exception)HttpContext.Current.Cache["LastError"];
        if (ex != null)
            Label1.Text = ex.Message;
    }
}

Note SessionID not there if anonymous user, and ex.Data.Add a key that's already there will cause error making me realize it's important to call ClearError

Darrell
This could display another error to the user. since the cache can be changed from when it's inserted to when it's displayed.
Carl Bergquist
A: 
Server.ClearError();

This line should be placed on Error.aspx.cs after displaying ErrorMessage I think.

Alex Do