在软件服务中使用包含错误代码的异常或字符串

发布于 2024-08-19 13:13:03 字数 183 浏览 4 评论 0原文

我们正在为客户的网站创建一个应用程序。该网站将对我们的应用程序进行函数调用以生成 XML 数据,我们将其作为字符串返回。如果我们在处理过程中出现问题,我们应该如何报告这个错误?我们应该抛出一个异常让客户端的网站捕获,还是应该返回一个包含错误代码(而不是 XML 数据)的字符串?哪个有意义和/或者是更好的做法?

预先感谢您对我们的帮助!

We are creating an application for a client's website. The website will make a function call to our application to generate XML data, which we will return as a String. If something goes wrong during the course of our processing, how should we report this error? Should we throw an Exception for the client's website to catch, or should we return a String containing the error code (instead of the XML data)? Which makes sense and/or is the better practice?

Thank you in advance for helping us out!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

是伱的 2024-08-26 13:13:03

我认为有两种方法可以做到这一点。

  1. 将错误字符串元素包含到每个 Web 服务功能的响应元素中。如果为空,则函数调用成功。如果已设置,则存在异常,错误字符串会告诉您原因。
  2. 使用 SOAP-Fault 元素进行异常处理。我认为每个 SOAP 工具包都提供了一种填充此元素的方法(例如,查看 gSoap Framework http://www.cs.fsu.edu/~engelen/soapdoc2.html#tth_sEc11

I think there are two ways you can do that.

  1. Include an Error-String Element into the Response-Element of every Web-Service Function. If it is empty, then the function call was succesful. If it is set, then there was an exception and the Error-String tells you the reason.
  2. Use the SOAP-Fault Element for exception handling. I think every SOAP-Toolkit offers a way to fill this Element (for Example look at gSoap Framework http://www.cs.fsu.edu/~engelen/soapdoc2.html#tth_sEc11)
指尖凝香 2024-08-26 13:13:03

我倾向于说错误代码几乎总是一个坏主意。异常提供了一个合理的默认错误处理方案:如果您不处理它,您就有效地断言它不会在您的情况下发生。如果你错了,你的程序会很快失败,并带有清晰的错误消息。返回代码不提供此类保证。这里的默认行为是错误被隐藏起来,程序继续运行,就像什么都没发生一样。

此规则的例外情况:

  1. 如果错误非常小,则像什么也没发生一样继续是比崩溃更好的默认设置。
  2. 在资源非常有限的环境中(即非服务器),异常的代价可能会很高。

I'm inclined to say that error codes are almost always a bad idea. Exceptions provide a sane default error handling scheme: If you don't handle it, you effectively assert that it can't happen in your situation. If you're wrong, your program fails fast and with a clear error message. Return codes offer no such guarantees. The default behavior here is that the error gets swept under the rug and the program continues as if nothing happened.

Exceptions to this rule:

  1. If the error is very minor, such that continuing as if nothing happened is a better default than crashing.
  2. In very resource-constrained environments (i.e. not servers), exceptions can be expensive.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文