我改变了上面的@Mecki的答案，让method1在调用方法中返回一个布尔值和一个检查，因为你不能用什么都不替换一个异常。在运行两次之后，method1仍然是最快的或者和method2一样快。

下面是代码的快照:

// Calculates without exception
public boolean method1(int i) {
    value = ((value + i) / i) << 1;
    // Will never be true
    return ((i & 0xFFFFFFF) == 1000000000);

}
....
   for (i = 1; i < 100000000; i++) {
            if (t.method1(i)) {
                System.out.println("Will never be true!");
            }
    }

和结果:

运行1

method1 took 841 ms, result was 2
method2 took 841 ms, result was 2
method3 took 85058 ms, result was 2

运行2

method1 took 821 ms, result was 2
method2 took 838 ms, result was 2
method3 took 85929 ms, result was 2

供你参考，我扩展了Mecki做的实验:

method1 took 1733 ms, result was 2
method2 took 1248 ms, result was 2
method3 took 83997 ms, result was 2
method4 took 1692 ms, result was 2
method5 took 60946 ms, result was 2
method6 took 25746 ms, result was 2

前3个和Mecki的一样(我的笔记本电脑明显慢一些)。

method4和method3是一样的，除了它创建了一个新的Integer(1)而不是抛出一个新的Exception()。

method5类似于method3，除了它创建了新的Exception()而不抛出它。

Method6和method3很像，只是它会抛出一个预先创建的异常(一个实例变量)，而不是创建一个新异常。

在Java中，抛出异常的大部分开销是收集堆栈跟踪所花费的时间，这发生在创建异常对象时。抛出异常的实际成本虽然很大，但比创建异常的成本要小得多。

不幸的是，我的回答太长了，不能在这里发表。所以让我在这里总结一下，并向你推荐http://www.fuwjax.com/how-slow-are-java-exceptions/以获得更具体的细节。

这里真正的问题不是“与“从未失败的代码”相比，“将失败报告为异常”的速度有多慢?”，正如人们所接受的回答可能会让你相信的那样。相反，问题应该是“与其他方式报告的失败相比，‘作为异常报告的失败’有多慢?”通常，报告失败的另外两种方法是使用哨兵值或使用结果包装器。

哨兵值是在成功情况下返回一个类，在失败情况下返回另一个类的尝试。你几乎可以把它看作是返回一个异常而不是抛出一个异常。这需要一个与success对象共享的父类，然后执行“instanceof”检查和几个类型转换来获得成功或失败的信息。

事实证明，冒着类型安全的风险，Sentinel值比异常快，但仅快大约2倍。现在，这可能看起来很多，但2倍只包括实现差异的成本。实际上，这个因素要低得多，因为我们可能失败的方法要比本页其他地方示例代码中的几个算术运算符有趣得多。

另一方面，结果包装器根本不牺牲类型安全。它们将成功和失败信息包装在单个类中。因此，它们提供了一个“isSuccess()”来代替“instanceof”，并为成功和失败对象提供了getter。但是，结果对象大约比使用异常慢2倍。事实证明，每次创建一个新的包装器对象比有时抛出异常要昂贵得多。

最重要的是，异常是语言提供的一种指示方法可能失败的方式。没有其他方法可以仅从API判断哪些方法总是(大部分)工作，哪些方法报告失败。

异常比哨兵更安全，比结果对象更快，并且比两者都不那么令人惊讶。我并不是建议用try/catch替换if/else，但是异常是报告失败的正确方式，即使在业务逻辑中也是如此。

也就是说，我想指出的是，我遇到的两种最常见的实质上影响性能的方法是创建不必要的对象和嵌套循环。如果可以在创建异常和不创建异常之间选择，请不要创建异常。如果要在有时创建异常或始终创建另一个对象之间做出选择，那么就创建异常。

不知道这些主题是否相关，但我曾经想实现一个依赖于当前线程的堆栈跟踪的技巧:我想发现方法的名称，它触发了实例化类中的实例化(是的，这个想法很疯狂，我完全放弃了它)。所以我发现调用Thread.currentThread(). getstacktrace()是非常慢的(由于本机的dumpThreads方法，它在内部使用)。

相应地，Java Throwable有一个本地方法fillInStackTrace。我认为前面描述的kill -catch块以某种方式触发了该方法的执行。

但让我告诉你另一个故事……

在Scala中，一些函数特性是使用ControlThrowable在JVM中编译的，它扩展了Throwable，并以以下方式覆盖了它的fillInStackTrace:

override def fillInStackTrace(): Throwable = this

所以我调整了上面的测试(循环量减少了十，我的机器有点慢:):

class ControlException extends ControlThrowable

class T {
  var value = 0

  def reset = {
    value = 0
  }

  def method1(i: Int) = {
    value = ((value + i) / i) << 1
    if ((i & 0xfffffff) == 1000000000) {
      println("You'll never see this!")
    }
  }

  def method2(i: Int) = {
    value = ((value + i) / i) << 1
    if ((i & 0xfffffff) == 1000000000) {
      throw new Exception()
    }
  }

  def method3(i: Int) = {
    value = ((value + i) / i) << 1
    if ((i & 0x1) == 1) {
      throw new Exception()
    }
  }

  def method4(i: Int) = {
    value = ((value + i) / i) << 1
    if ((i & 0x1) == 1) {
      throw new ControlException()
    }
  }
}

class Main {
  var l = System.currentTimeMillis
  val t = new T
  for (i <- 1 to 10000000)
    t.method1(i)
  l = System.currentTimeMillis - l
  println("method1 took " + l + " ms, result was " + t.value)

  t.reset
  l = System.currentTimeMillis
  for (i <- 1 to 10000000) try {
    t.method2(i)
  } catch {
    case _ => println("You'll never see this")
  }
  l = System.currentTimeMillis - l
  println("method2 took " + l + " ms, result was " + t.value)

  t.reset
  l = System.currentTimeMillis
  for (i <- 1 to 10000000) try {
    t.method4(i)
  } catch {
    case _ => // do nothing
  }
  l = System.currentTimeMillis - l
  println("method4 took " + l + " ms, result was " + t.value)

  t.reset
  l = System.currentTimeMillis
  for (i <- 1 to 10000000) try {
    t.method3(i)
  } catch {
    case _ => // do nothing
  }
  l = System.currentTimeMillis - l
  println("method3 took " + l + " ms, result was " + t.value)

}

所以，结果是:

method1 took 146 ms, result was 2
method2 took 159 ms, result was 2
method4 took 1551 ms, result was 2
method3 took 42492 ms, result was 2

你看，method3和method4之间唯一的区别是它们会抛出不同类型的异常。是的，method4仍然比method1和method2慢，但是差异是可以接受的。

即使抛出异常并不慢，对于正常的程序流抛出异常仍然是一个坏主意。使用这种方式，它是类似于GOTO…

我想这并没有真正回答问题。我想抛出异常的“传统”智慧在早期的java版本(< 1.4)中是正确的。创建异常需要虚拟机创建整个堆栈跟踪。从那时起，在VM中发生了很多变化，以加快速度，这可能是已经改进的一个领域。

为什么异常回报率会比正常回报率慢呢?

只要不将堆栈跟踪输出到终端，将其保存到一个文件或类似的文件中，catch块就不会比其他代码块做更多的工作。所以，我无法想象为什么“throw new my_cool_error()”应该这么慢。

好问题，我期待关于这个话题的进一步信息!