How is the best way to handle any occuring errors in a Sivlerlight application?
I am not talking about error handling in a development environment.
But what would be the best way to log errors and look them up for fute reference?
+1
A:
I typically do not like to rely solely on Silverlight to display the errors in a meaningful way to the client (i.e "Problem loading data..."). Rather I prefer to wrap up the exception and make a call back to my server via a WCF service with an exposed method to accept the Silverlight exception as a parameter. Once on the server, you can log it to the event log, text log, email to the support group etc.
The real key here is to get that exception beck from the client and on to your server to be handled in the best and most communicable manner.
atconway
2010-09-12 13:08:28
+1
A:
The technique I use is logging to both the server, and client. You do this through one entry point, a Log class with a number of static methods, or a singleton if you prefer. This can then be configured to do just client logging, just server, both or none.
The client log can then be displayed in a non-panic inducing dialog, where the full stacktrace is available in a toggle'able text box. This obviously allows for exceptions to be caught if the web service is down, or broken. It also lets the user copy the stacktrace and email it you if they're particularly irate.
Although server logging (for example with Log4Net) is more powerful as it gives a lot more options for logging including email alerts, it does rely on you being able to find the exception for the particular person, which requires additional search tools or knowledge in the case of the event log.
Having the addition of client logging to fall back on (with server logging on as well) is in my view a worthwhile extra feature.
Chris S
2010-09-13 10:21:24
"where the full stacktrace is available in a toggle'able text box." Be very careful when choosing this option. If you are speaking of a SL contol in a controled intranet application then you should be fine. However if this is a SL control exposed on the internet, showing the stack trace can be a security risk. You do not want to give up any of the details to the client in regards to the exception that could expose the innerworkings of your code.
atconway
2010-09-13 13:08:36
@Atconway they can just unzip the XAP up and look in reflector anyway :)
Chris S
2010-09-13 18:20:45
True, but using a Reflector for unzipping the .zap file will not give you "INSERT into MyTableName failed. No such parameter @UserID at MyServiceDALMethod.Save(String Val1, StringVal2)" all in a single message. Plus the code can be obfuscated to help prevent using a decompiler if there is something really secret on the client. I think the general concensus is to "not" show the client the full stack trace, unless you are testing, etc.
atconway
2010-09-14 12:29:54
@atconway That kind of error would be in the eventargs.Error property though, and wouldn't be unhandled. I can see your point however, I don't think it's one choice or the other it depends on how technical your target audience are
Chris S
2010-09-15 17:16:03