It doesn’t exist! That could actually be my entire blogpost, but you’d be left there with a rather disturbed feeling. So we’ll get into detail.
If you have a web service (say, an .asmx file), and you’re planning on it returning JSON into the page, you’ll pop your usual ScriptServiceAttribute in, and get on with it. A few months later, you’re running happily in production, and suddenly you see some requests failing with an HTTP 500 status. How do they fail? An HTTP header comes back as follows:
jsonerror: true
And instead of the nice JSON you were expecting, you get this:
{"Message":"Server was unable to process request","ExceptionType":""}
Well, that’s pretty annoying. That didn’t happen when you built this service. Something must be wrong with the data you’re trying to return. In debug, this would be showing the actual exception and type, but of course you followed best practice and deployed in retail mode, which turned on custom errors. But no problem, let’s have a look in the application’s error log – luckily, you used ELMAH to log all server exceptions.
Nope, ELMAH is showing nothing. How very odd. After a brief check, you realize that it must be because errors in .asmx methods don’t go through Application_Error. No problem, you’ll just have to bite the bullet and check the Windows Event Log.
Nothing is there. The plot thickens.
As far as I know, there’s nothing you can now do except turn off Custom Errors and inspect the problem. There doesn’t seem to be any way to get a hold of it. The great Ayende appears to have experienced a great deal of frustration at this! As always in programming, there will be a way – but I cannot think of a tidy and effective way of making error handling work.
If you’re having this same issue, you might want to assume that there is a problem with serializing a particular type (if you’re returning complex types); or that your total response is larger than permitted by the MaxJsonLength set in the web.config.
Recent Comments