Josh Bloch在《Effective Java》中广泛地讨论了这个主题。他的建议很有启发性，也适用于。net(细节除外)。

特别地，例外应用于特殊情况。原因主要与可用性有关。对于一个给定的方法，要最大限度地使用，它的输入和输出条件应该受到最大限度的约束。

例如，第二种方法比第一种方法更容易使用:

/**
 * Adds two positive numbers.
 *
 * @param addend1 greater than zero
 * @param addend2 greater than zero
 * @throws AdditionException if addend1 or addend2 is less than or equal to zero
 */
int addPositiveNumbers(int addend1, int addend2) throws AdditionException{
  if( addend1 <= 0 ){
     throw new AdditionException("addend1 is <= 0");
  }
  else if( addend2 <= 0 ){
     throw new AdditionException("addend2 is <= 0");
  }
  return addend1 + addend2;
}

/**
 * Adds two positive numbers.
 *
 * @param addend1 greater than zero
 * @param addend2 greater than zero
 */
public int addPositiveNumbers(int addend1, int addend2) {
  if( addend1 <= 0 ){
     throw new IllegalArgumentException("addend1 is <= 0");
  }
  else if( addend2 <= 0 ){
     throw new IllegalArgumentException("addend2 is <= 0");
  }
  return addend1 + addend2;
}

无论哪种情况，都需要检查以确保调用者正确地使用了您的API。但在第二种情况下，您需要它(隐式地)。如果用户没有读取javadoc，软异常仍然会被抛出，但是:

你不需要记录它。 你不需要测试它(取决于你的攻击性有多强 单元测试策略是)。 您不需要调用者处理三个用例。

最基本的一点是，异常不应该用作返回代码，很大程度上是因为你不仅让你的API变得复杂了，还让调用者的API变得复杂了。

当然，做正确的事情是有代价的。代价是每个人都需要理解他们需要阅读和遵循文档。希望是这样。

我认为您可以使用异常进行流控制。然而，这种技术也有另一面。创建异常是一件代价高昂的事情，因为它们必须创建堆栈跟踪。因此，如果你想更频繁地使用异常，而不仅仅是发出异常情况的信号，你必须确保构建堆栈跟踪不会对你的性能产生负面影响。

减少创建异常成本的最佳方法是重写fillInStackTrace()方法，如下所示:

public Throwable fillInStackTrace() { return this; }

这样的异常不会填充堆栈跟踪。

异常基本上是非本地的goto语句，具有后者的所有结果。在流控制中使用异常违反了最小惊奇原则，使程序难以阅读(请记住，程序首先是为程序员编写的)。

而且，这不是编译器供应商所期望的。他们希望很少抛出异常，并且他们通常让抛出代码非常低效。抛出异常是。net中最昂贵的操作之一。

然而，一些语言(尤其是Python)使用异常作为流控制结构。例如，如果没有其他项，迭代器将引发StopIteration异常。即使是标准的语言结构(比如for)也依赖于此。

标准的回答是，异常是不正常的，应该在特殊情况下使用。

其中一个对我来说很重要的原因是，当我在维护或调试的软件中读取try-catch控制结构时，我试图找出为什么最初的编码器使用异常处理而不是if-else结构。我希望能找到一个好的答案。

请记住，您不仅为计算机编写代码，还为其他编码员编写代码。有一个与异常处理程序相关联的语义，您不能仅仅因为机器不介意就将其丢弃。

让我们假设您有一个做一些计算的方法。它必须验证许多输入参数，然后返回一个大于0的数字。

使用返回值来表示验证错误，这很简单:如果方法返回的数字小于0，则发生错误。如何判断哪个参数无效?

我记得在我学习C语言的时候，很多函数返回的错误代码是这样的:

-1 - x lesser then MinX
-2 - x greater then MaxX
-3 - y lesser then MinY

etc.

它真的比抛出和捕获异常的可读性更差吗?

一般来说，在低级别处理异常本身并没有什么问题。异常是一个有效的消息，它提供了一个操作为什么不能执行的很多细节。如果你能接受，你就应该接受。

一般来说，如果你知道有很高的失败概率，你可以检查…你应该去检查一下…即if(obj != null) obj.method()

在你的情况下，我对c#库不够熟悉，不知道date time是否有一种简单的方法来检查时间戳是否越界。如果是，只需调用If (.isvalid(ts)) 否则，您的代码基本上没问题。

所以，归根结底，这取决于哪种方式可以创建更干净的代码……如果防止预期异常的操作比处理异常更复杂;那么你就有我的权限来处理异常，而不是到处创建复杂的守卫。