Wally
Exception handling is also very important for me. - Definitively missing. Glad to see a timeout feature !
Yes, it's one of the things that are missing right now. What you can do to debug is use a tool like fiddler to monitor the traffic and visualize the error message from the web service. Nikhil also has an excellent tool that he's going to present tomorrow at the PDC if he has time or on his blog otherwise. Stay tuned...
In which session will the tool be shown?
CIAO
Michael
It's not only while developing and debugging where you need exceptions. Many regular situations can be handled more effeciently using them.
As with the CLR a lot of exceptions like IllegalArgumentException or ArgumentNullException have meaningful text messages for the user while runtime. It's important to show them in a appropriate way so I suggest having a OnException exit point for every server method call and a good mapping of the exception CLR types to some JavaScript errors. I haven't found a good solution for this yet.
I think we need something similar like the .error property I have added in Ajax.NET Professional. Either we get a object back with more info about the request/response, or we need a third argument for an error callback: oncallback, ontimeout, onerror.
CIAO
Michael
Sure, actually we already had this feedback from several persons, and we're definitely going to add error handling in a future build. For the moment, you can use a fiddler-like tool. Nikhil's presentation is tomorrow at 5:00PM.
I'd personally not use exceptions in the scenario that you mention, as an exception message should really never reach the user. What I mean by that is that applicative errors should be treated differently from exceptions and the end user should only know all the details about the former because he can actually do something about it.
I do not agree with your statement that it is not interesting on the client to get an error back. I think there are two different errors:
- one, that will occur on the .NET code and returns a System.Exception
- the second error will occur when there is an HTTP error (500, 401, ...)
Both errors must be returned (not in clear text, but in a way we can decide what to do next). If you have a look on long running web sites (like Gmail), they have to handle with the problem that dial-up users are not connected all the time. In this scenario we need to get an error.
CIAO
Michael
bleroy wrote:
an exception message should really never reach the user...
I don't want to start a religious programming style war here. I've seen both opinions and the all where reasonable in their cases.
We will get "errors" on the client when in offline mode or disconnected. These states we have to handle with. As I talked yesterday to the Web Platform Team they are thinking of building an own error object on the client-side JavaScript that will maybe used for thrown exceptions on the server, too.
<BLOCKQUOTE><table width="85%"><tr><td class="txt4"><img src="http://pics.10026.com/?src=/Themes/default/images/icon-quote.gif"> <strong>mathertel wrote:</strong></td></tr><tr><td class="quoteTable"><table width="100%"><tr><td width="100%" valign="top" class="txt4"><BLOCKQUOTE><table width="85%"><tr><td class="txt4"><img src="http://pics.10026.com/?src=/Themes/default/images/icon-quote.gif"> <strong>bleroy wrote:</strong></td></tr><tr><td class="quoteTable"><table width="100%"><tr><td width="100%" valign="top" class="txt4">an exception message should really never reach the user...</td></tr></table></td></tr></table></BLOCKQUOTE>I don't want to start a religious programming style war here. I've seen both opinions and the all where reasonable in their cases.</td></tr></table></td></tr></table></BLOCKQUOTE>
Me neither. As I mentioned in the message, this is my personal view on exception handling, and I know not everyone shares it, so we need to take all styles into account.
<BLOCKQUOTE><table width="85%"><tr><td class="txt4"><img src="http://pics.10026.com/?src=/Themes/default/images/icon-quote.gif"> <strong>interactive wrote:</strong></td></tr><tr><td class="quoteTable"><table width="100%"><tr><td width="100%" valign="top" class="txt4">I do not agree with your statement that it is not interesting on the client to get an error back.</td></tr></table></td></tr></table></BLOCKQUOTE>
Never said that. I was talking about exceptions, not errors. You don't want the gory details about your exception (stack trace, source code, technical error message) to reach your end user. It's useless to him and it's a security risk. That's the reason for the customErrors setting in ASP.NET for example. Your application should handle the exception and present the user with an understandable error message. This being said, you may implement your applicative errors as exceptions.
No comments:
Post a Comment