ASP.Net Ajax, Error Handling and WTF
I am facing some really unpleasant choices at the moment. And I thought it would be so easy.
I wanted to add global error handling to all the web services that we expose as [ScriptService].
For some reason, they didn't show up in the Application_Error event, and that caused the exception details to be sent to the client.
It looks like for some strange reasons, web services exceptions don't go through the Application_Error, so I implemented a SoapExtension to handle that, but ScriptService doesn't go through the Soap layers, so it obviously doesn't work.
Then I went and looked at the code.
The whole thing is _hard coded_ inside, and there is no way in.
No way to globally capture exception being raised from script services.
No way in to add this ability.
Urgh! Argh!
I mean, it is not like I want something very special, it sounds to me like a reasonable request.
Yes, I know you can turn off the error in the config, but I would like, you know, to log this.
Of course, everything is internal in there, so I can't just go and override the RestHandler. ExecuteWebServiceCall(), I would have to have a private build of this stuff.
Just to be able to log exceptions.
Comments
I'm assuming you're working with ASP.Net on this one.
You should use the ScriptManager.AsyncPostBackError event.
If you inherited from ScriptManager before using it - just write some in "myScriptManager" that catchs the exception and logs it.
If you havn't inherited the ScriptManager but are using a BasePage you can get the ScriptManager via: "ScriptManager.GetCurrent(this.Page)" and then hook up into it's events.
Additionally, using the "AsyncPostBackErrorMessage" you can change the error message to something friendly like "Something happened. We logged it. Don't worry about it" from inside the event's EventHandler.
Justin,
No, there isn't a script manager involved, because I am talking specifically about using script services only.
If it is throwing an exception, could you use the AppDomain UnhandledException event to trap those that are not passed through the application_error?
Fred,
It is not unhandled.
It is handled in a way that is not appropriate.
It's still a very young product, and script services are brand new. This is the kind of feedback they would like, but probably with a little less derision and scorn.
El,
Error handling is a key part of any product.
Sorry, getting it wrong. Getting it that wrong is very bad.
Getting it that wrong and having no way in to fix it, even worse.
Ugh... that's not pleasant!
Just a thought - but couldn't you get at least get partial exception coverage (excluding serialization issues occurring outside of the method call) by using PostSharp with an OnException aspect - at least you're only having to decorate each class with a single attribute to get some logging then.
Admittedly not a nice solution... but it's better then no logging at all ;o)
I probably could, but I don't want to introduce it now.
Going to byte code weaving just to get logging on exceptions is crazy.
Desperate times call for desperate measures - I wouldn't seriously consider introducing PostSharp at such a later hour either, that way lays madness.
I wonder what the rationale to write it that way was to begin with.
ASP.NET in some places is the worst Microsoft framework I have ever seen.
The only kind of unsolvable problems my team hits periodically is the underpowered serialization model whiich is also nearly unextensible.
Maybe you can take a look at the following:
http://weblogs.asp.net/rashid/archive/2007/09/19/new-project-asp-net-ajax-exception-logging.aspx