做过SOAP的请进：服务模块异常俘获(200分)

最近我也在做soap这方面的研究，有兴趣的可以用qq跟我联系。...请著名dwf
qq:45523902
email : feifan731@163.net
 
SOAP 出现的 "无效的 xml 声明" 等的错误一般是服务端方法没有写对。
正常情况下服务端不需要去俘获，让它直接丢到客户端来。如果客户端
传入的参数有问题（不严密）时也会出现上述错误。
如果在服务端去俘获结果是一样的。
一般的，写SOAP服务时，可以写两个工程，一个的发布版的（CGI或ISAPI），
一个是调试版（COM）。这样错误在调试期去处理。发布时只需换一个工程文件
重编译即可。
我将错误分成两种，一种是可预见的（容错），一种是不可预见的（异常），
分别处理。
 
丢，如何丢？你不管它一般是不会丢到客户端来的，或者丢过来的已经面目全非了。
“既不曾拥有，又何以付出？”
你没有俘获到，又如何丢过来？
 
学习
 
如果你在服务端的方法里没有使用 try..except..end 之类的语句，当客户端调用这个方法出错时，自动会把出错信息在客户端抛出，你可以在客户端用 try 去俘获.
 
版主不解决问题，我就要猛灌了，我也没办法。

楼主对不起，我不能提问，借用一下。
 
我比较同意 bundur 的说法。
我用soap 写的目前情况就是如此。
好好学习
 
先前就是因为在服务器端有些地方没有去俘获异常，结果就是客户端有时能够俘获到真正发生的异常，有时就是如前所说的"无效的 xml 声明" ，现在我在每个方法中都俘获异常，客户端收到的异常就是明确的。
服务端的程序除了实现的功能不同外，其它的和客户端程序也没多大差别，肯定也会有许多地方要进行异常处理的，否则，我很难理解你如何控制程序逻辑。
在这里我是希望设计一种统一的异常俘获陷阱，至于是否应该在服务端进行异常处理还是另题再论吧
 
在我的平台程序设计里，在服务器端，我是有做异常处理的，处理完后只是返回给客户端服务端方法调用是否成功的标志，如果客户想知道调用在哪里出错了，可以通过 GetErrorCode 或 GetSvcError 两个服务端错误处理的方法来返回具体的错误信息。
我这样的处理是模仿了 Windows APIs 的 LastError 的处理方式。
 
to bundur
你的方法就是没有利用soap的优势, 在传统的windows API中, 考虑到在不同语言中传递复杂对象实现很困难, exception object不容易传递, 所以用ErrorCode或LastError的方法.
但在web service里, 传递复杂对象是很容易的, 而且soap里有专门的exception处理机制,
他不仅可以自动返回exception object, 还可以返回exception stack. 客户端只要写try
except end块就行了.用不着返回值或error code来处理exception
 
我之所以这样做，是因为我不想在客户端对服务端方法的调用时都使用 try...except...end，以保证只要连通就一定可以成功调用，方法的返回值是客户端直接所需要的，但在这个返回值中有一个特定值来表示调用远程方法失败的，这时如果需要处理再调用 error code，以保证其通用性。因为大部分的异常在发布前都是可以解决的。
还有通过 try...except...end 俘获的异常通常是作为调试时用的，我一般会将它们直接写入一个 Error.Log 中做为错误处理的技术文档的一部分，而提示给用户的却是我们已知的导致错误的实际原因，所有未知的错误原因，我们可能使用“系统异常”等信息告诉用户要解决这样的异常需要找我们的技术支持人员。
其实API对于不同的语言中传递复杂对象实现是通过地址指针的，API的方法也多用指针赋值和传参。
 
俺是菜鸟
关注，学习中……
 
bundur,
是因为我不想在客户端对服务端方法的调用时都使用 try...except...end
在soap连接时, 有很多不可知情况发生, try...except...end是很必要的, 去掉它并不会给你带来多少方便, 但会带来很多麻烦. 你可以用转换exception message的方法去给用户你们已知的自己的消息, 对于你们不知道的exception, 可直接打印系统exception message.

其实API对于不同的语言中传递复杂对象实现是通过地址指针的，API的方法也多用指针赋值和传参。
地址指针只是单机的概念, 在分布式系统中, 地址指针是没用的.


 
to: yyanghhong
> 直接打印系统exception message
我个人认为没有必要，用户不想看到他看不懂的错误信息，那样他可能会误认为系统不稳定。
不过我说的只是我的个人经验和做法。“地址指针只是单机的概念”这毫无疑问的。
我个人做产品软件的经验比较多，所以更多的会考虑自己处理程序里可能的例外，以减少客户对出错信息的疑问。这是以牺牲部分的性能换取的。比如数据库的例外完全可以交给数据库系统去处理...
 
欢迎加入
中国人资网[IT人才网,中国人才网]
免费注册，免费发布信息！！！
http://www.ithrok.com
IT@ITHROK.COM
 
我还不知道什么东西来的
 
记得有个 SoapException 之类的东东吧，服务器端的异常都是以 SoapException 异常抛给客户端。
服务器不用把一个异常通过一个RemoteTable类传递到客户端吧，这不搞复杂了吗？
 
本人觉得java的异常处理就很好,DELPHI中就算抓住异常,他对系统消息的处理也是很麻烦的.
 
关 注
 
您必须登录或注册才可回复。

Similar threads

X
kbmmw 做REST 服务签名认证的一种方式 - xalion
回复
0
查看
686
xalion
X
S
[原]Delphi2010中DataSnap高级技术(3)—DataSnap服务器如何得到客户端的IP和端口
回复
0
查看
1K
SUNSTONE的Delphi笔记
S
S
[原]Delphi2010中DataSnap高级技术(3)—DataSnap服务器如何得到客户端的IP和端口
回复
0
查看
1K
SUNSTONE的Delphi笔记
S
S
[转]ClientDataSet加上TDataSetProvider的数据保存问题
回复
0
查看
3K
SUNSTONE的Delphi笔记
S
S
[转]ClientDataSet加上TDataSetProvider的数据保存问题
回复
0
查看
2K
SUNSTONE的Delphi笔记
S
顶部