3

我正在设计一个 API（第一次），它将是一个非常公开的 API（用于免费在线服务）。

我正在考虑返回结构，例如InsertResult哪个可以具有失败或成功时的属性（即多少行），错误消息等等。现在，另一种方法是从 API 插入方法中抛出异常。我知道这是一个“一般和开放”的问题，但是对于 API，什么被认为更干净和优美？

设想

API 是一个 DLL（它在内部调用和使用来自 4 或 5 个不同来源的 Web 服务，并且取决于地理位置等决定与哪个服务交互）。它是使用 C# 和 Mono 构建的。使用场景包括来自桌面、移动和 Web 客户端的 API 作为库。这确实是问题所在，假设一个离线用例，从网络客户端它根本不会发生，但从移动设备或桌面它可以（更频繁地从移动设备）那该怎么办？如何在离线时管理说插入调用以存储来自移动应用程序的模拟。或者当另一个（与服务器相关的）错误发生时。

4

5 回答 5

2

一般来说，如果用户试图做一些无效的事情，你应该抛出一个异常。但是，您还应该提供一个代码路径，允许用户在发生异常之前合理地检查可能引发异常的条件。如果它很重要（可能出于性能原因），您可能希望包含一个TryInsert安全处理无效插入并简单地返回bool有效以指示成功的方法。

这适用于纯 C# API 以及服务 API。

于 2013-03-27T21:27:35.657 回答
2

抛出异常是在 C#/.NET 中处理错误和意外情况的更自然的方式。此外，.NET 为您提供了定义自己的异常或使用现有异常之一的可能性。
此外，通过提供诸如finally{}-blocks 之类的东西，您可以在出现问题时创建非常顺利的操作。
检查返回值很容易出错，如果用户没有正确地对您的返回值做出反应，它可能会使过程不稳定。未处理的异常通常会停止进程，因此会强制用户检查背景。不过，这是我的看法。

在MSDN上，他们说，抛出异常是一个很好的理由，例如，如果参数错误并且您不能继续使用错误的输入。

于 2013-03-27T21:27:47.940 回答
2

由于问题是“一般性和开放性”，我认为如果我们考虑最常用的网络服务，如谷歌、亚马逊，我认为它们都遵循尽可能精确地提供细节的原则，这样任何使用它的人都知道他们做错了什么。

如果您只是抛出异常，那么您的 API 的用户可能会给您带来更多的错误。

因此，总结一下定义众所周知的错误代码并将相同的信息传递给客户/消费者总是一个好主意，这样他们就可以很容易地找出呼叫有什么问题或者我应该做些什么来纠正它。仅出于某种原因您的 api 仅接受特定编码的示例，然后用户会对此感到沮丧。

于 2013-03-27T21:29:19.397 回答
2

我建议返回一个详细的错误。由于您使用 Web 服务进行消费，因此并非每个人都会使用相同的技术与之交互。如果您在哪里制作框架，那么我会说使用异常，因为开发人员将使用相同的技术来使用它。在框架级别，这是异常更有用的地方。

更新（有问题的 API 实际上是一个框架）： 由于您现在正在谈论使用框架，因此您应该抛出异常，因为客户端必须引用 DLL 并且将了解可能的框架异常。要使用这些库，它必须是符合 CLR 的语言，因此它们应该具有相同的概念、类、异常等......

于 2013-03-27T21:36:39.583 回答
0

对于 API，异常总是更好。API 使用者可以使用 catch 块处理各种异常。如果您使用错误消息和错误代码，则要求您的 API 使用者编写 If 语句。下面的代码片段总是比你有 If 条件来检查错误的东西更干净。

因此，从 API 消费者的角度来看，API 抛出异常总是更干净

try
{
    yourAPIClass.YourMethod();
}
catch(YourException1 ex)
{
   action1();

}
catch(YourException2 ex)
{
   action1();

}

这是编写和抛出异常的一个很好的指南 http://blogs.msdn.com/b/kcwalina/archive/2005/03/16/396787.aspx

于 2013-03-27T21:30:59.793 回答