The topics I’ve been posting about lately have been somewhat varied; from Internet culture to hockey to politics to random thoughts. Remember when I went on and on about programming? Me too, so here goes.

This is for any ASP.NET coders out there Google-ing “There was an error processing the request”. I recently came across this issue, so I wanted to share what I’ve found to resolve it. You’ve probably written an awesome web service with public methods that do awesome things and are so meticulously coded so as to adhere to all the hip programming concepts and best practices. I’d bet that you’re doing the right thing in your web service’s public methods by capturing code that’s prone to throwing exceptions like this:

namespace FooService
{
    [WebMethod(EnableSession=true)]
    public void Foo()
    {
        try
        {
            // Dangerous method alert
            MyWildMethod();
        }
        catch (Exception ex)
        {
            // Handle with grace.
            CleanupWildMethod();

            throw new Exception("Something happened - no worries.");
        }
    }
}

Perhaps you’re calling this web service method via AJAX on your presentation layer pages and expecting this to come back in get_message():

function UseMyWebService()
{
    FooService.Foo(SuccessCallback, ErrorCallback);
}
 
function ErrorCallback(error)
{
    alert('Whoa: ' + error.get_message());
}

And it does in your development environment. Then you deploy this to production and your lovely and friendly “Something happened…no worries” message turns into the user-unfriendly “There was an error processing the request” message. What gives?

There’s a good chance that you’re using custom error pages in your project. Your Web.config might have something like this in it:

<customerrors mode="On">
      <error statusCode="403" redirect="~/error.aspx?eid=403" />
      <error statusCode="500" redirect="~/error.aspx?eid=500" />
      <error statusCode="501" redirect="~/error.aspx?eid=501" />
      <error statusCode="502" redirect="~/error.aspx?eid=502" />
</customerrors>

If you do, you’ve successfully determined that users should see friendly error pages rather than cryptic ones that only programmers would understand. Unfortunately, Microsoft hasn’t figured this out yet and instead of allowing the user-friendly message in your exception to propagate back, they replace it with “There was an error processing the request”. There is a solution. You could set the customErrors mode to “Off”, but that would defeat the purpose. Instead, ensure that your web service ASMX files are in a folder of their own. Then, inside of that folder, create a basic Web.config that looks like this:

< ?xml version="1.0"?>

<configuration>
    <appsettings />
    <connectionstrings />
    <system .web>
      <customerrors mode="Off" />
    </system>
</configuration>

That’s all it takes to correct this oversight on Microsoft’s part.