AJAX. It’s not just for your kitchen counters anymore.
That being said, I’ve encountered an interesting oddity with Microsoft’s ASP.NET AJAX library.
Those of you used to working with the .NET 2.0 Framework will be unsurprised to know that error handling through the standard ways (that is, PageError, ApplicationError and such), sucks when utilizing the ASP.NET AJAX Toolkit. That’s cause the original toolkit would prevent these standard error handlers from firing.
At my work, I’ve tried to implement some of this methodology to improve my own user’s happiness. Sadly, it’s proved more irritating than anything else.
Since we utilize an all Microsoft network of machines, we utilize all Microsoft technologies. Thus, their ASP.NET AJAX framework came with it, such that we didn’t have to write our own calendar-date-picking widgets and such.
This all started way back when, before the .NET 3.5 Framework came out. Now, 3.5 implements the AJAX Toolkit natively.
Neat, you would think.
What wasn’t neat, was that I was (re-)tasked (the “re-” part is a long story) with creating graceful error handling for both our AJAX-enabled pages, and our standard pages. All signs pointed that we should be handling true, server-side page errors with the global error handler, known as Application_Error. And along side, the AJAX toolkit required it’s own error handling. Which wasn’t difficult.
All was good.
Until we upgraded to .NET 3.5.
It turns out .NET 3.5 re-enables application level errors with Application_Error. And no one bothered to tell anyone about it.
Which broke all the error handling I ever built.