确认理解 - Web服务异常 [英] Confirm understanding - web service exceptions

问题描述

如果我调用一个Web服务，它会引发异常，如果客户端应用程序是.Net应用程序，我可以看到

异常。但是，如果客户端应用程序是
而不是.Net应用程序，我只会收到HTTP 500错误。我认为这应该是因为非.Net应用程序使用的是POST而不是SOAP。如果

非.Net应用程序使用SOAP，它们实际上也会看到

例外。这是真的？谢谢！

If I invoke a web service, and it throws an exception, I can see the
exception if the client app is a .Net app. However, if the client app is
not a .Net app, I only receive the HTTP 500 error. I believe this is due
mostly to the fact that the non-.Net apps are using POST instead of SOAP. If
the non-.Net apps were using SOAP, they too would in fact "see" the
exception. Is this true? Thanks!

推荐答案

我认为这里有两个独立的问题 - 非网络应用程序处理soapfaults

不同，我已经与一个其序列化程序捕获并重新抛出它的异常类型，另一个没有 - 尽管它可以告诉它

重组其中一个有效的基础对象类型，我们不得不手动

检查每次调用后对象的属性。编译事项

Web服务方法并不能保证它会抛出SoapException，所以我们确保从我们的Web服务方法中我们只抛出派生的

SoapException，我们知道客户可以解释。


至于帖子和http状态500 - 我只遇到过.net

Web服务收到了它无法解释的请求，例如当

客户端期望rpc-cencoding或命名空间未被识别时。否则

服务仍然应该返回状态200的故障，至于我知道...


r 。

" Marty McDonald" < MC ****** @ wsdot.wa.gov>在留言中写道

新闻：％2 **************** @ TK2MSFTNGP10.phx.gbl ...

there are two separate issues here i think - non-net apps handle soapfaults
differently, i''ve worked with one whose serialiser caught and re-threw it as
its Exception type, and another that didnt -as far as it could tell it
reconstituted one of its valid base Object types, and we had to manually
check the proprties of the object after each call. to compilcate matters a
web service method doesnt guarantee it will throw a SoapException, so we
ensured that, from our web service methods, we only threw a derived
SoapException that we knew the client could interpret.

as for posts and http status 500 - i''ve only encountered that when a .net
web service received a request it couldnt interpret, for example when the
client expected rpc-cencoding, or the namespace wasnt recognised. otherwise
the service should still return the fault with a status 200, so far as i
know...

r.
"Marty McDonald" <mc******@wsdot.wa.gov> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

如果我调用一个Web服务，并抛出异常，如果客户端应用程序是.Net应用程序，我可以看到
异常。但是，如果客户端应用程序不是.Net应用程序，我只会收到HTTP 500错误。我认为这主要是因为非.Net应用程序使用的是POST而不是SOAP。
如果非.Net应用程序使用SOAP，它们实际上也会看到
例外。这是真的？谢谢！

If I invoke a web service, and it throws an exception, I can see the
exception if the client app is a .Net app. However, if the client app is
not a .Net app, I only receive the HTTP 500 error. I believe this is due
mostly to the fact that the non-.Net apps are using POST instead of SOAP. If the non-.Net apps were using SOAP, they too would in fact "see" the
exception. Is this true? Thanks!

感谢您的回复。但是，我仍然不确定我的网站

服务应如何处理异常。也许这会有所帮助......

我认为当一个Web服务传播异常时，ASP.Net会为客户做两件事：
两件事：

A - 如果客户端通过SOAP调用服务，ASP.Net将向客户端返回

异常。

B - 如果客户端调用了通过POST服务，ASP.Net将回复

HTTP 500，因为POST需要HTTP代码，而不是例外。

换句话说，ASP.Net知道协议用于调用web

服务，并返回适合该协议的任何内容。


所以...如果我希望所有客户都收到同样的异常响应

无论协议如何，我的Web服务都应该捕获（而不是
传播）异常并将其他内容返回给客户端。所以我会决定如何回应客户而不是让ASP.Net决定。

那是我想要与其他人确认的那种策略所以我知道

这种方法是有道理的，并且基于对ASP / Net如何处理传播异常的正确理解。


Robbie Harris <为RO *********** @ hotmail.com>在消息中写道

新闻：bj ********** @sparta.btinternet.com ...

Thanks for the reply. However, I''m still a little unsure about how my web
services should handle exceptions. Maybe this will help...
I think that when a web service propagates an exception, ASP.Net will do one
of two things for the client:
A - if the client invoked the service via SOAP, ASP.Net will return the
exception to the client.
B - if the client invoked the service via POST, ASP.Net will respond with
HTTP 500, because POST expects an HTTP code, not an exception.
In other words, ASP.Net knows the protocol that was used to invoke the web
service, and returns whatever is appropriate for that protocol.

So... If I wanted all clients to receive the same kind of exception response
regardless of their protocol, my web service should catch (instead of
propagate) exceptions and return something else to the client. So I will
decide how to respond to the client instead of letting ASP.Net decide.
That''s the kind of strategy that I wanted to confirm with others so I''d know
the approach makes sense and is based on the proper understanding of how
ASP.Net handles propagated exceptions.

"Robbie Harris" <ro***********@hotmail.com> wrote in message
news:bj**********@sparta.btinternet.com...

我认为这里有两个不同的问题 - 非网络应用程序以不同的方式处理
soapfaults，我曾与一个其序列化程序捕获并重新抛出它的
作为其异常类型，另一个没有 - 尽管它可以告诉它 Web服务方法并不能保证它会抛出SoapException，所以我们确保从我们的Web服务方法中，我们只抛出了一个派生的SoapException，我们知道客户端可以对于帖子和http状态500的解释 - 我只遇到过.net
网络服务收到了无法解释的请求，例如
客户端预期rpc-cencoding，或命名空间未被识别。
否则该服务仍然应该返回状态200的错误，只要我知道......

r。

" Marty麦当劳" < MC ****** @ wsdot.wa.gov>在消息中写道
新闻：％2 **************** @ TK2MSFTNGP10.phx.gbl ...

there are two separate issues here i think - non-net apps handle soapfaults differently, i''ve worked with one whose serialiser caught and re-threw it as its Exception type, and another that didnt -as far as it could tell it
reconstituted one of its valid base Object types, and we had to manually
check the proprties of the object after each call. to compilcate matters a
web service method doesnt guarantee it will throw a SoapException, so we
ensured that, from our web service methods, we only threw a derived
SoapException that we knew the client could interpret.

as for posts and http status 500 - i''ve only encountered that when a .net
web service received a request it couldnt interpret, for example when the
client expected rpc-cencoding, or the namespace wasnt recognised. otherwise the service should still return the fault with a status 200, so far as i
know...

r.
"Marty McDonald" <mc******@wsdot.wa.gov> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

如果我调用一个Web服务，它会引发异常，如果客户端应用程序是.Net应用程序，我可以看到
异常。但是，如果客户端应用程序
不是.Net应用程序，我只会收到HTTP 500错误。我认为这是
，主要是因为non.Net应用程序使用的是POST而不是

If I invoke a web service, and it throws an exception, I can see the
exception if the client app is a .Net app. However, if the client app is not a .Net app, I only receive the HTTP 500 error. I believe this is due mostly to the fact that the non-.Net apps are using POST instead of

SOAP。如果

SOAP. If

非.Net应用程序使用SOAP，它们实际上也会看到
例外。这是真的？谢谢！

the non-.Net apps were using SOAP, they too would in fact "see" the
exception. Is this true? Thanks!

我没有和http-post客户合作过 - 所以我就是没有专家 - 但我会不会在b
客户端调用的基础上改变服务错误处理策略 - 曾经不得不部署两个版本的对于

文档和文字编码的相同服务，我不愿意想到增加的复杂性

自定义异常处理！我可以理解为什么一个.net web

服务异常会导致邮件客户端出现500错误，但是我会知道b $ b还有兴趣知道其他人是否在这个团队用一个

统一的方法很好地解决了这个问题。


r。


" Marty McDonald" < MC ****** @ wsdot.wa.gov>在消息中写道

新闻：Ov ************* @ TK2MSFTNGP11.phx.gbl ...

i''ve not worked with http-post clients - so i''m no expert - but i''d be
loathe to change the service error handling strategy on the basis of the
client call - having once had to deploy two versions of the same service for
document and literal encoding, i''d hate to think of the added complexity of
customising exception handling on top! i can understand why a .net web
service exception would result in a 500 error for a post client, but i''d
also be interested to know if others in this group sovled this well with a
unified approach.

r.

"Marty McDonald" <mc******@wsdot.wa.gov> wrote in message
news:Ov*************@TK2MSFTNGP11.phx.gbl...

感谢您的回复。但是，我仍然不确定我的网站服务应如何处理异常。也许这会有所帮助......
我认为当Web服务传播异常时，ASP.Net将为客户端执行
两件事之一：
A - 如果客户端调用了通过SOAP服务，ASP.Net将向客户端返回
异常。
B - 如果客户端通过POST调用服务，ASP.Net将以HTTP 500响应，因为POST预计一个HTTP代码，而不是一个例外。
换句话说，ASP.Net知道用于调用web服务的协议，并返回适合该协议的任何内容。
响应而不管其协议如何，我的Web服务应该捕获（而不是传播）异常并将其他内容返回给客户端。所以我将决定如何回应客户而不是让ASP.Net做出决定。
这就是我想与其他人确认的那种策略所以我要
知道这种方法是有道理的，并且基于对ASP.Net如何处理传播异常的正确理解。

Thanks for the reply. However, I''m still a little unsure about how my web
services should handle exceptions. Maybe this will help...
I think that when a web service propagates an exception, ASP.Net will do one of two things for the client:
A - if the client invoked the service via SOAP, ASP.Net will return the
exception to the client.
B - if the client invoked the service via POST, ASP.Net will respond with
HTTP 500, because POST expects an HTTP code, not an exception.
In other words, ASP.Net knows the protocol that was used to invoke the web
service, and returns whatever is appropriate for that protocol.

So... If I wanted all clients to receive the same kind of exception response regardless of their protocol, my web service should catch (instead of
propagate) exceptions and return something else to the client. So I will
decide how to respond to the client instead of letting ASP.Net decide.
That''s the kind of strategy that I wanted to confirm with others so I''d know the approach makes sense and is based on the proper understanding of how
ASP.Net handles propagated exceptions.

这篇关于确认理解 - Web服务异常的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！