加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 编程开发 > asp.Net > 正文

asp.net – 在try / catch块中包装Web服务

发布时间:2020-12-16 07:13:49 所属栏目:asp.Net 来源:网络整理
导读:将Web服务方法/调用包装到try / catch块中是最佳做法吗? 我不知道Web服务请求往往是.NET桌面应用程序崩溃的原因吗?所以我认为所有调用应该包含在try / catch中以防止这种情况发生. 好主意? 它是应该抛出异常还是只有空捕获? 解决方法 我假设您正在使用WC
将Web服务方法/调用包装到try / catch块中是最佳做法吗?

我不知道Web服务请求往往是.NET桌面应用程序崩溃的原因吗?所以我认为所有调用应该包含在try / catch中以防止这种情况发生.

好主意?

它是应该抛出异常还是只有空捕获?

解决方法

我假设您正在使用WCF,因为您的问题已被标记.使用WFC进行异常处理的一个好习惯是不允许异常通过线路传递给消费者,而是抛出有意义的FaultExceptions.

如果有可能由它生成异常,您应该在操作中始终使用try … catch块.如果允许原始感知冒泡,则只会产生两种情况:如果您已将服务配置为允许出现故障中的异常详细信息,则会为安全漏洞而自行打开服务内部.或者您没有在服务中配置此功能,并且消费者会收到一条非常通用的消息,指出出现了问题,这对他们或支持团队来说并不是很有用.

您应该做的是声明一个或多个FaultExceptions,具体取决于您希望用户从您的操作接收的消息,在操作声明中将它们装饰为FaultContracts.然后你可以尝试…捕获特定的异常并抛出特定的错误.你也可以尝试捕获异常并抛出非常一般的错误.

关键在于,没有透露太多关于内部操作的信息 – 尤其是堆栈跟踪!

错误只是另一个数据契约,因此它在您的WSDL中声明.这意味着您的消费者可以专门捕获故障并且可以对从您的操作引发的错误做出反应,就好像它是从代码抛出的异常一样.

希望这可以帮助.

乔.

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读