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

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

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

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

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

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

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

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

HotSpot非常能够删除系统生成的异常代码，只要它是内联的。但是，显式创建的异常和其他未删除的异常要花费大量时间来创建堆栈跟踪。重写fillInStackTrace以查看这会如何影响性能。

我已经扩展了@Mecki和@incarnate给出的答案，没有为Java填充stacktrace。

在Java 7+中，我们可以使用Throwable(String message, Throwable cause, boolean enableSuppression,boolean writableStackTrace)。但是对于Java6，请参阅我对这个问题的回答

// This one will regularly throw one
public void method4(int i) throws NoStackTraceThrowable {
    value = ((value + i) / i) << 1;
    // i & 1 is equally fast to calculate as i & 0xFFFFFFF; it is both
    // an AND operation between two integers. The size of the number plays
    // no role. AND on 32 BIT always ANDs all 32 bits
    if ((i & 0x1) == 1) {
        throw new NoStackTraceThrowable();
    }
}

// This one will regularly throw one
public void method5(int i) throws NoStackTraceRuntimeException {
    value = ((value + i) / i) << 1;
    // i & 1 is equally fast to calculate as i & 0xFFFFFFF; it is both
    // an AND operation between two integers. The size of the number plays
    // no role. AND on 32 BIT always ANDs all 32 bits
    if ((i & 0x1) == 1) {
        throw new NoStackTraceRuntimeException();
    }
}

public static void main(String[] args) {
    int i;
    long l;
    Test t = new Test();

    l = System.currentTimeMillis();
    t.reset();
    for (i = 1; i < 100000000; i++) {
        try {
            t.method4(i);
        } catch (NoStackTraceThrowable e) {
            // Do nothing here, as we will get here
        }
    }
    l = System.currentTimeMillis() - l;
    System.out.println( "method4 took " + l + " ms, result was " + t.getValue() );


    l = System.currentTimeMillis();
    t.reset();
    for (i = 1; i < 100000000; i++) {
        try {
            t.method5(i);
        } catch (RuntimeException e) {
            // Do nothing here, as we will get here
        }
    }
    l = System.currentTimeMillis() - l;
    System.out.println( "method5 took " + l + " ms, result was " + t.getValue() );
}

输出与Java 1.6.0_45，在Core i7, 8GB RAM:

method1 took 883 ms, result was 2
method2 took 882 ms, result was 2
method3 took 32270 ms, result was 2 // throws Exception
method4 took 8114 ms, result was 2 // throws NoStackTraceThrowable
method5 took 8086 ms, result was 2 // throws NoStackTraceRuntimeException

因此，返回值的方法仍然比引发异常的方法更快。恕我直言，我们不能仅仅为成功流和错误流使用返回类型来设计一个清晰的API。在没有stacktrace的情况下抛出异常的方法比普通异常快4-5倍。

谢谢@Greg

public class NoStackTraceThrowable extends Throwable { 
    public NoStackTraceThrowable() { 
        super("my special throwable", null, false, false);
    }
}

我对异常速度和以编程方式检查数据的看法。

许多类都有字符串到值的转换器(扫描器/解析器)，也有受人尊敬和知名的库;)

通常有形式

class Example {
public static Example Parse(String input) throws AnyRuntimeParsigException
...
}

异常名称只是例子，通常是未选中的(运行时)，所以抛出声明只是我的图片

有时存在第二种形式:

public static Example Parse(String input, Example defaultValue)

不扔

当第二个文件不可用时(或者程序员读的文档太少，只使用第一个文件)，用正则表达式编写这样的代码。正则表达式很酷，政治正确等:

Xxxxx.regex(".....pattern", src);
if(ImTotallySure)
{
  Example v = Example.Parse(src);
}

使用这段代码，程序员没有异常成本。BUT具有相当高的代价的正则表达式ALWAYS与小的代价异常有时。

我几乎总是在这种情况下使用

try { parse } catch(ParsingException ) // concrete exception from javadoc
{
}

没有分析堆栈跟踪等，我相信在你的讲座后相当快。

不要害怕例外情况

我改变了上面的@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

比较一下，假设是Integer。将parseInt转换为以下方法，该方法在不可解析数据的情况下只返回默认值，而不会抛出异常:

  public static int parseUnsignedInt(String s, int defaultValue) {
    final int strLength = s.length();
    if (strLength == 0)
      return defaultValue;
    int value = 0;
    for (int i=strLength-1; i>=0; i--) {
      int c = s.charAt(i);
      if (c > 47 && c < 58) {
        c -= 48;
        for (int j=strLength-i; j!=1; j--)
          c *= 10;
        value += c;
      } else {
        return defaultValue;
      }
    }
    return value < 0 ? /* übergebener wert > Integer.MAX_VALUE? */ defaultValue : value;
  }

只要您将这两种方法应用于“有效”数据，它们将以大致相同的速率工作(即使Integer。parseInt设法处理更复杂的数据)。但是当您试图解析无效数据时(例如解析“abc”1.000.000次)，性能上的差异应该是至关重要的。