I’ve reported a bug over on connect with the full details, but basically what it boils down to is that there’s no way to raise exception detail from ScriptMethods when ASP.NET custom error handling is enabled. What happens is that the RestHandler for ScriptMethods detects the custom error handling is enabled and literally throws out all the details of the exception and returns a generic message instead. This pretty much makes it impossible to know what happened on the server. Did it fail to connect to the DB or was there a business logic problem that the user needs to rectify? Who knows? Obviously the only workaround is to turn off customErrors, but for production code that’s dangerous and strongly recommended against.
I find it extremely hard to recommend using the entire ASP.NET AJAX web service scripting stack to anyone doing even moderately complex enterprise web applications. I’ve suggested a couple of approaches to solving the problem in the bug report. If you find this as important as I do, please go vote the bug up… it’s not too late to at least get them to return the type of exception. Looking at the IL, it’s a one line change, I don’t know how they can reject it if they want people to take the framework seriously.
FYI, this is in both the 1.0 web extensions and also in 3.5 (beta 2) now that the extensions have been baked into the framework.
Update 8/7/07 4:27PM ET:
It just got marked as Resolved (By Design). The excuse was they can’t propagate the type as it might expose internal details, which is fine because I agree it’s a risk, but they also don’t have time to handle a special exception type which is BS. Since they’re hijacking the ASMX stack, they just need to watch for SoapException subtypes and let them out. Good call MS. Way to ensure your AJAX framework, which is facing stiff competition from several other parties, will never be considered for a “real” application anytime soon.*sigh*
This is why rolling everything into the .NET framework is completely asinine. ASP.NET should never have been in the framework to begin with, it makes sense to evolve completely independently and not even be shipped to the client machine by default (think of all the bloat it sends to the average windows user that will never be used). Next they did it with W[P|C|W]F and now they did it with the ASP.NET extensions. It just guarantees these things can’t/won’t evolve at a pace that is demanded by the rest of the industry. We can’t wait years for a .NET framework update just to have a problem like this fixed. The CTPs are nice, but they’re not go live-able and even they have become few and far between.