从 .NET Web 服务抛出异常
我有一组使用 [WebMethod] 属性生成的 Web 服务。如果没有正确指定参数（并且无法使用合理的默认值），那么从这样的方法中抛出 ArgumentException 是否被认为是“良好实践”？如果是这样，是否应该捕获并重新抛出此异常，以便将其记录在服务器和客户端上？
I have a set of web services generated using the [WebMethod] attribute. Is it considered "good practice" to throw ArgumentException from such a method if its arguments aren't properly specified (and no sensible defaults could be used)? If so, should this exception be caught and re-thrown in order to log it both on the server and the client?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不，从 Web 服务抛出异常不是一个好习惯，因为 .NET 异常（如
ArgumentException）不支持跨平台（想想 Java 客户端需要如何响应）。用于指示 Web 服务中的异常的标准机制是 Soap 故障。
使用
.asmx，抛出 SOAPException 将为您生成一个错误。如果您迁移到 WCF，可以查看 FaultContracts。
为了改进 .Net 客户端和 .Net 服务器之间的远程异常调试，您可以使用 includeExceptionDetailInFaults 在您的配置中。异常本身必须是可序列化的才能使其正常工作。但是，您需要在系统投入生产之前关闭此功能。
顺便说一句，您经常会发现，如果调用者的 SOAP 请求调用格式太差（例如，如果您的参数包含无法反序列化的实体），则您的
WebMethod根本不会被调用- 调用者只会收到一个错误（通常非常神秘）。当验证调用参数时，应该会生成因客户端调用服务的错误参数而引发的上述错误。
可能相关 - 一旦请求通过验证，对于您自己的内部系统状态断言，您还可以使用 代码契约来检测内部错误（或者可能缺少应该早点发生的验证）。然而，这些不会传播给客户。
No, throwing exceptions from web services is not good practice, as .NET Exceptions (like
ArgumentException) aren't supported cross platform (think of how a Java client would need to respond).The standard mechanism for indicating exceptions in Web Services is a Soap Fault.
With
.asmx, throwing a SOAPException will generate a fault for you.If you move to WCF, you can look at FaultContracts.
For improved debugging of remote exceptions between a .Net client and .Net server, you could cheat and send an exception across the wire by using includeExceptionDetailInFaults in your config. The exception itself must be serializable in order for this to work. However, you will want to turn this off before your system reaches production.
As an aside, you will often find that if the caller's SOAP request call is too poorly formed (e.g. if your arguments include entities that can't be deserialized) that your
WebMethodwon't be called at all - the caller will just receive a fault (often quite cryptic).The above faults raised for bad arguments from the client's call to your service should be generated when the call arguments are validated.
Possibly related - Once a request has passed validation, for your own internal system state assertion, you could also use Code Contracts to detect internal bugs (or possibly, missing validations which should have happened earlier). These however will not be propogated to the client.
使用异常与自定义错误代码始终是一个艰难的决定。您应该估计这种情况有多“特殊”，以及您计划如何处理消费者方面的错误。使用异常通常是意外情况（例如缺少重要参数）和自定义错误代码来处理类似业务的错误。
更新：这当然仅适用于您创建新服务的情况。如果您修改现有客户端，则必须了解现有客户端如何使用它以及他们如何期望错误代码。
Using Exceptions vs custom error codes is always a hard decision. You should estimate, how 'exceptional' the case is and how do you plan to handle the error on the consumer side. Use exception is normally unexpected cases (like an important parameter is missing) and custom error codes to handle bussiness-like errors.
UPDATE: this of course only applies, if you are creating a new service. If you modify an existing one, you have to know how the existing clients use it and how they expect error codes.
这里是关于 Web 服务异常的好文章
Here is a nice article about web service exceptions