我继承了 WCF 服务，它充当文件缓存（每个文件代表对第三方 API 的请求的结果）。目前，如果文件不存在，代码会创建一个新请求来创建数据，并且还会向客户端代码引发异常。
我认为这个想法是客户会回来再次请求文件，然后他们就可以使用它（生成文件需要几秒钟）。
我认为这里有代码味道，我应该重写这部分。目前，异常正在通过几种方法被捕获并冒泡。我想我应该在源代码中确定文件是否存在并将该信息传递到调用堆栈。
在 WCF 界面，我目前有一个 GetValue() 方法，但我认为可以使用两个选项来替换它：
null。bool TryGetValue(string key, out string value) 方法有没有人有任何偏好/建议？
谢谢
【问题讨论】：
标签： c# wcf exception-handling trygetvalue
“TryGet”方法更加明确。使用返回 null 的方法，您必须记录该方法出于某种原因返回 null，这需要开发人员阅读文档。众所周知，有些人对阅读文档过敏。
“TryGet”方法的另一个优点是，您可以使用枚举而不是布尔值，向调用者提供有关方法失败（或成功）的原因和方式的更多信息。
Jeffrey Richter（C# 中的 CLR）对异常的定义：当动作成员无法完成其任务时，该成员应抛出异常。异常意味着操作成员未能完成其名称所指示的应执行的任务。我的问题是我应该保持 GetValue 方法对客户端可用，并在数据不可用时引发错误，还是将其删除并用 TryGetValue() 替换？
Jeffrey Richter 的定义在您确定 API 的设计时没有帮助，因为这包括确定每个操作成员的任务应该是什么。
在您的设计中，您理所当然地希望该值不可用；这意味着值不可用并不是一种例外情况。因此我会只使用 TryGet...模式。
但是，说实话，我会采用完全不同的方法。假设有人尝试这种方法：
while (!TryGetValue(key, out value)) {}
或：
SomeType value;
bool flag = false;
while (!flag)
{
try
{
value = GetValue(key);
flag = true;
}
catch {}
}
您的 WCF 服务将获得大量点击。研究异步模型可能会更好，因此当结果准备好时通过回调通知客户端，而不是邀请客户端不断轮询服务。
【讨论】：