Silverlight应用程序中的错误处理
问题描述:
答
我用的就是登录到两个服务器和客户端的技术。你可以通过一个入口点,一个Log
类和许多静态方法来实现,或者如果你愿意的话可以使用单例。这可以配置为只执行客户端日志记录,只是服务器,两者都不是。
客户端日志就可以诱导对话框,其中完整堆栈跟踪可在一个toggle'able文本框显示在非恐慌。这显然允许在Web服务停止或中断时捕获异常。它还可以让用户复制堆栈跟踪并发送给你,如果他们特别愤怒。
尽管服务器日志记录功能(例如Log4Net)功能更强大,它为日志记录提供了更多选项,包括电子邮件警报,但它确实依赖于您能够为特定人员找到例外情况,这需要额外的搜索工具或在事件日志的情况下的知识。
在我看来,增加客户端日志记录功能是一个值得追加的功能。
答
我通常不喜欢仅仅依靠Silverlight来显示以有意义的方式错误给客户端(即“问题加载数据......”)。相反,我更愿意包装异常,并通过WCF服务通过一个公开的方法回调我的服务器,以接受Silverlight异常作为参数。一旦在服务器上,您可以将其记录到事件日志,文本日志,电子邮件到支持组等。
这里真正的关键是要从客户端获取该异常,并将其传递到要处理的服务器上最好的和最传播的方式。
“其中完整堆栈跟踪处于toggle'able文本框可用。”选择此选项时要非常小心。如果您在控制的Intranet应用程序中提到SL控件,那么您应该没问题。但是,如果这是在互联网上暴露的SL控制,则显示堆栈跟踪可能是安全风险。关于可能暴露代码内部结构的异常,您不想放弃任何细节。 – atconway 2010-09-13 13:08:36
@Atconway他们可以将XAP解压缩并反射回来:) – 2010-09-13 18:20:45
确实如此,但是使用反射器解压缩.zap文件不会给你“插入到MyTableName失败。没有这样的参数@UserID at MyServiceDALMethod.Save字符串Val1,StringVal2)“全部在一条消息中。此外,如果客户端上有真正的秘密,代码可能会被混淆以帮助防止使用反编译器。我认为大家的共识是“不”向客户展示完整的堆栈跟踪,除非您正在测试等。 – atconway 2010-09-14 12:29:54