如果你想在每个迭代中捕获Exception，或者检查哪个迭代抛出了Exception，并捕获迭代中的每个Exception，放置try…在循环内捕获。如果发生异常，这将不会中断循环，并且您可以在整个循环的每次迭代中捕获每个异常。

如果你想打破循环并在抛出异常时检查异常，请使用try…从循环中捕获。这将打破循环并在catch(如果有的话)之后执行语句。

这完全取决于你的需要。我更喜欢用try…如果Exception发生，结果不会有歧义，并且循环不会中断并完全执行。

在你的例子中没有功能上的区别。我觉得你的第一个例子可读性更强。

性能:就像Jeffrey在他的回复中所说的，在Java中这并没有太大的区别。

通常，为了代码的可读性，在哪里捕获异常的选择取决于您是否希望循环继续处理。

在您的示例中，您在捕获异常时返回。在这种情况下，我会在循环中放入try/catch。如果你只是想捕捉一个坏值，但继续处理，把它放在里面。

第三种方法:您总是可以编写自己的静态ParseFloat方法，并在该方法中而不是在循环中处理异常处理。使异常处理与循环本身隔离!

class Parsing
{
    public static Float MyParseFloat(string inputValue)
    {
        try
        {
            return Float.parseFloat(inputValue);
        }
        catch ( NumberFormatException e )
        {
            return null;
        }
    }

    // ....  your code
    for(int i = 0; i < max; i++) 
    {
        String myString = ...;
        Float myNum = Parsing.MyParseFloat(myString);
        if ( myNum == null ) return;
        myFloats[i] = (float) myNum;
    }
}

把它放在里面。您可以继续处理(如果您愿意)，也可以抛出一个有用的异常，告诉客户端myString的值和包含坏值的数组的索引。我认为NumberFormatException已经告诉您坏的值，但原则是将所有有用的数据放在您抛出的异常中。考虑一下在程序的调试器中，您会对什么感兴趣。

考虑:

try {
   // parse
} catch (NumberFormatException nfe){
   throw new RuntimeException("Could not parse as a Float: [" + myString + 
                              "] found at index: " + i, nfe);
} 

在需要的时候，您将非常感谢这样一个异常，其中包含尽可能多的信息。

如果你想在每个迭代中捕获Exception，或者检查哪个迭代抛出了Exception，并捕获迭代中的每个Exception，放置try…在循环内捕获。如果发生异常，这将不会中断循环，并且您可以在整个循环的每次迭代中捕获每个异常。

如果你想打破循环并在抛出异常时检查异常，请使用try…从循环中捕获。这将打破循环并在catch(如果有的话)之后执行语句。

这完全取决于你的需要。我更喜欢用try…如果Exception发生，结果不会有歧义，并且循环不会中断并完全执行。

好吧，在Jeffrey L Whitledge说没有性能差异之后(截至1997年)，我去测试了一下。我运行了一个小的基准测试:

public class Main {

    private static final int NUM_TESTS = 100;
    private static int ITERATIONS = 1000000;
    // time counters
    private static long inTime = 0L;
    private static long aroundTime = 0L;

    public static void main(String[] args) {
        for (int i = 0; i < NUM_TESTS; i++) {
            test();
            ITERATIONS += 1; // so the tests don't always return the same number
        }
        System.out.println("Inside loop: " + (inTime/1000000.0) + " ms.");
        System.out.println("Around loop: " + (aroundTime/1000000.0) + " ms.");
    }
    public static void test() {
        aroundTime += testAround();
        inTime += testIn();
    }
    public static long testIn() {
        long start = System.nanoTime();
        Integer i = tryInLoop();
        long ret = System.nanoTime() - start;
        System.out.println(i); // don't optimize it away
        return ret;
    }
    public static long testAround() {
        long start = System.nanoTime();
        Integer i = tryAroundLoop();
        long ret = System.nanoTime() - start;
        System.out.println(i); // don't optimize it away
        return ret;
    }
    public static Integer tryInLoop() {
        int count = 0;
        for (int i = 0; i < ITERATIONS; i++) {
            try {
                count = Integer.parseInt(Integer.toString(count)) + 1;
            } catch (NumberFormatException ex) {
                return null;
            }
        }
        return count;
    }
    public static Integer tryAroundLoop() {
        int count = 0;
        try {
            for (int i = 0; i < ITERATIONS; i++) {
                count = Integer.parseInt(Integer.toString(count)) + 1;
            }
            return count;
        } catch (NumberFormatException ex) {
            return null;
        }
    }
}

我使用javap检查了结果字节码，以确保没有任何内容得到内联。

结果表明，假设JIT优化微不足道，Jeffrey是正确的;在Java 6、Sun客户端VM上绝对没有性能差异(我没有访问其他版本)。整个测试的总时间差在几毫秒的数量级上。

因此，唯一要考虑的是什么看起来最干净。我发现第二种方式很难看，所以我要么坚持第一种方式，要么坚持雷·海耶斯的方式。