如果将try/catch放在循环中，则会在异常发生后继续循环。如果你把它放在循环之外，你会在抛出异常时立即停止。

你应该喜欢外面的版本而不是里面的版本。这只是规则的一个特定版本，将任何可以移动到循环外的东西移动到循环外。根据IL编译器和JIT编译器的不同，您的两个版本最终可能具有不同的性能特征，也可能没有。

另一方面，你可能应该看看float。TryParse或Convert.ToFloat。

这取决于故障处理。如果你只是想跳过error元素，请尝试内部:

for(int i = 0; i < max; i++) {
    String myString = ...;
    try {
        float myNum = Float.parseFloat(myString);
        myFloats[i] = myNum;
    } catch (NumberFormatException ex) {
        --i;
    }
}

在任何其他情况下，我宁愿到外面去试试。代码更可读，更干净。如果返回null，在错误情况下抛出一个IllegalArgumentException可能会更好。

As already mentioned, the performance is the same. However, user experience isn't necessarily identical. In the first case, you'll fail fast (i.e. after the first error), however if you put the try/catch block inside the loop, you can capture all the errors that would be created for a given call to the method. When parsing an array of values from strings where you expect some formatting errors, there are definitely cases where you'd like to be able to present all the errors to the user so that they don't need to try and fix them one by one.

如果这是一个全有或全无的失败，那么第一种格式是有意义的。如果希望能够处理/返回所有未失败的元素，则需要使用第二种形式。这些就是我选择方法的基本标准。就我个人而言，如果是孤注一掷，我不会使用第二种形式。

上面没有提到的另一个方面是，每个try-catch都会对堆栈产生一些影响，这可能会对递归方法产生影响。

如果方法"outer()"调用方法"inner()"(它可能递归地调用自己)，如果可能的话，尝试在方法"outer()"中找到try-catch。我们在性能类中使用的一个简单的“堆栈崩溃”示例，当try-catch在内部方法中时，在大约6400帧时失败，当它在外部方法中时，在大约11,600帧时失败。

在现实世界中，如果您正在使用Composite模式并且具有大型、复杂的嵌套结构，这可能会成为一个问题。