Question

如果我正在编写一个从字符串中解析出来的API，那么从一个带有“out”值的方法中分离parse方法是个好主意吗？

我认为是的原因是代码会更清晰。例如。如果我得到一个与解析相关的异常，我可以在堆栈中说“啊，是的，那将是一个名为Parse（）的顶级方法！”甚至在查看代码库之前。我认为null是错误的选择，因为它可能会引入其他开发人员的错误，这些开发人员不了解所做的技术决策（尽管我这是宗教的）。

但是，在堆栈深度为5级的方法中，我怎么能“中继”错误字符串消息？

由于

Answer 1

你应该抛出ArgumentException。

Answer 2

为了传递错误字符串消息，请创建一个例外并使用“throw”关键字。

至于分离解析方法，这是你要求的吗？

int myInt;
if(!Int32.TryParse(inputString, out int myInt))
    throw new System.ArgumentException("Invalid Argument", "inputString");

methodThatUsesInt(myInt);

Answer 3

你的问题有点不清楚。你是说你的方法接受一个字符串，它应该是一个解析为整数，然后用这种解析的数字结果做某事吗？

如果你的方法不太可能被输入很多无效的字符串，并且如果你的例程没有任何用处，如果它收到一个无效的字符串，那么你的方法可能最好在传入无效的字符串。如果你的方法进行了足够复杂的解析，那么调用者无法很好地验证字符串而不需要像你的例程那样做很多的工作来解析它，你的例程将被要求处理所有好的字符串在包含好字符串和坏字符串混合的批处理中，常见的模式是以bool TryParse(string st, ref int result)的方式公开方法。就个人而言，我不喜欢这种模式，因为它没有提供指示解析失败原因的机制。我会推荐一种不同的模式 - 类似于以下之一：

int TryParse(string st, out ParseStatus status);
int TryParse(string st, Action<ParseStatus> failureAction);
delegate void ActionRV<RefT,ValT>(ref RefT refparam, ValT valparam);
int TryParse<RefPT>(string st, ActionRV<RefT, ParseStatus> FailureAction, 
                        ref RefT refParam);

在所有这三种调用模式中，如果ParseStatus是可继承类型，TryParse可以提供ParseStatus的实例或精确描述的ParseStatus派生类型失败。在第二个和第三个模式的情况下，委托可以自己抛出一个异常，在ParseStatus中存储一个应该返回给调用函数的值，或者做一些像munge原始参数字符串的东西（如果存储的话）在ref）并设置一个标志来请求“重试”。我个人喜欢第三种形式，因为我认为failureAction参数应该优先于闭包，以防任何一种形式起作用。请注意，第二种形式可以用第三种形式有效地实现：

static ExecAction<T>(T param, ref Action<T> proc)
{
  proc(param);
}
int TryParse(string st, Action<ParseStatus> failureAction)
{
  TryParse(st, ExecAction, ref failureAction);
}

请注意，将{{1}}作为ref参数传递意味着可以为包装函数使用静态委托，而不必使用闭包。

使用异常vs返回字符串作为消息

3 个答案: