Следует ли trycatch входить в цикл или вне его?

ПРЕДСТАВЛЕНИЕ:

Нет абсолютно никакой разницы в производительности в том, где размещаются структуры try / catch. Внутри они реализованы в виде таблицы диапазонов кодов в структуре, которая создается при вызове метода. Пока метод выполняется, структуры try / catch полностью не отображаются, если только не происходит выброс, затем местоположение ошибки сравнивается с таблицей.

Вот ссылка: http://www.javaworld.com/javaworld/jw-01-1997/jw-01-hood.html

Таблица описана примерно наполовину.

Производительность: как сказал в своем ответе Джеффри, в 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;
    }
}

Хорошо, после того как Джеффри Л. Уитледж сказал, что не было разницы в производительности (по состоянию на 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, Джеффри прав; нет абсолютно разницы в производительности на Java 6, клиентской виртуальной машине Sun (у меня не было доступа к другим версиям). Общая разница во времени составляет порядка нескольких миллисекунд за весь тест.

Поэтому единственное, что нужно учитывать - это то, что выглядит наиболее чистым. Я считаю, что второй способ уродлив, поэтому я буду придерживаться либо первого способа, либо Путь Рэя Хейса.

Хотя производительность может быть такой же, а то, что «выглядит» лучше, очень субъективно, все же существует довольно большая разница в функциональности. Возьмем следующий пример:

Integer j = 0;
    try {
        while (true) {
            ++j;

            if (j == 20) { throw new Exception(); }
            if (j%4 == 0) { System.out.println(j); }
            if (j == 40) { break; }
        }
    } catch (Exception e) {
        System.out.println("in catch block");
    }

Цикл while находится внутри блока try catch, переменная j увеличивается до 40, распечатывается, когда j mod 4 равен нулю, и возникает исключение, когда j достигает 20.

Прежде чем приступить к подробностям, приведу другой пример:

Integer i = 0;
    while (true) {
        try {
            ++i;

            if (i == 20) { throw new Exception(); }
            if (i%4 == 0) { System.out.println(i); }
            if (i == 40) { break; }

        } catch (Exception e) { System.out.println("in catch block"); }
    }

Та же логика, что и выше, с той лишь разницей, что блок try / catch теперь находится внутри цикла while.

Вот результат (в режиме try / catch):

4
8
12 
16
in catch block

И другой вывод (попробуйте / поймайте в то время):

4
8
12
16
in catch block
24
28
32
36
40

Вот вам и довольно существенная разница:

в то время как в try / catch выходит из цикла

попробуйте / поймайте, пока цикл остается активным

Я согласен со всеми сообщениями о производительности и удобочитаемости. Однако есть случаи, когда это действительно имеет значение. Еще пара людей упомянула об этом, но это может быть легче увидеть на примерах.

Рассмотрим этот слегка измененный пример:

public static void main(String[] args) {
    String[] myNumberStrings = new String[] {"1.2345", "asdf", "2.3456"};
    ArrayList asNumbers = parseAll(myNumberStrings);
}

public static ArrayList parseAll(String[] numberStrings){
    ArrayList myFloats = new ArrayList();

    for(int i = 0; i < numberStrings.length; i++){
        myFloats.add(new Float(numberStrings[i]));
    }
    return myFloats;
}

Если вы хотите, чтобы метод parseAll () возвращал null, если есть какие-либо ошибки (как в исходном примере), вы бы поместили try / catch снаружи следующим образом:

public static ArrayList parseAll1(String[] numberStrings){
    ArrayList myFloats = new ArrayList();
    try{
        for(int i = 0; i < numberStrings.length; i++){
            myFloats.add(new Float(numberStrings[i]));
        }
    } catch (NumberFormatException nfe){
        //fail on any error
        return null;
    }
    return myFloats;
}

На самом деле вам, вероятно, следует вернуть здесь ошибку вместо null, и, как правило, мне не нравится многократный возврат, но вы поняли идею.

С другой стороны, если вы хотите, чтобы он просто игнорировал проблемы и анализировал любые строки, которые он мог бы, вы бы поместили try / catch внутри цикла следующим образом:

public static ArrayList parseAll2(String[] numberStrings){
    ArrayList myFloats = new ArrayList();

    for(int i = 0; i < numberStrings.length; i++){
        try{
            myFloats.add(new Float(numberStrings[i]));
        } catch (NumberFormatException nfe){
            //don't add just this one
        }
    }

    return myFloats;
}

Как уже было сказано, производительность такая же. Однако пользовательский опыт не обязательно идентичен. В первом случае вы быстро потерпите неудачу (т.е. после первой ошибки), однако, если вы поместите блок try / catch внутри цикла, вы сможете зафиксировать все ошибки, которые будут созданы для данного вызова метода. При синтаксическом разборе массива значений из строк, где вы ожидаете некоторых ошибок форматирования, определенно есть случаи, когда вы хотите иметь возможность представить все ошибки пользователю, чтобы им не нужно было пытаться исправить их одну за другой. .

Если это не удается, то первый формат имеет смысл. Если вы хотите иметь возможность обрабатывать / возвращать все исправные элементы, вам необходимо использовать вторую форму. Это были бы мои основные критерии выбора между методами. Лично я бы не стал использовать вторую форму, если это все или ничего.

Пока вы знаете, что вам нужно выполнить в цикле, вы можете поместить try catch за пределы цикла. Но важно понимать, что цикл завершится, как только возникнет исключение, и это может не всегда быть тем, что вам нужно. На самом деле это очень распространенная ошибка в программном обеспечении на основе Java. Людям необходимо обработать ряд элементов, например очистить очередь, и ложно полагаться на внешний оператор try / catch, обрабатывающий все возможные исключения. Они также могут обрабатывать только конкретное исключение внутри цикла и не ожидать возникновения каких-либо других исключений. Затем, если возникает исключение, которое не обрабатывается внутри цикла, цикл будет «вытеснен», он, возможно, завершится преждевременно, и внешний оператор catch обработает исключение.

Если бы цикл был своей жизненной ролью, чтобы очистить очередь, то этот цикл, скорее всего, мог бы закончиться до того, как эта очередь действительно опустеет. Очень частая ошибка.

В ваших примерах нет функциональной разницы. Я считаю ваш первый пример более читабельным.

Вы должны предпочесть внешнюю версию внутренней версии. Это просто конкретная версия правила: перемещайте все, что находится за пределами цикла, что вы можете переместить за пределы цикла. В зависимости от компилятора IL и JIT ваши две версии могут иметь или не иметь разные характеристики производительности.

С другой стороны, вам, вероятно, следует посмотреть на float.TryParse или Convert.ToFloat.

Если вы поместите команду try / catch внутрь цикла, вы продолжите цикл после исключения. Если вы поместите его за пределы цикла, вы остановитесь, как только возникнет исключение.

Я считаю, что блоки try / catch необходимы для обеспечения правильной обработки исключений, но создание таких блоков влияет на производительность. Поскольку циклы содержат интенсивные повторяющиеся вычисления, не рекомендуется помещать блоки try / catch внутри циклов. Кроме того, кажется, что это условие часто перехватывается «Exception» или «RuntimeException». Следует избегать попадания RuntimeException в код. Опять же, если вы работаете в большой компании, важно правильно зарегистрировать это исключение или остановить возникновение исключения времени выполнения. Весь смысл этого описания PLEASE AVOID USING TRY-CATCH BLOCKS IN LOOPS

установка специального кадра стека для try / catch добавляет дополнительные накладные расходы, но JVM может обнаружить факт возврата и оптимизировать его.

в зависимости от количества итераций разница в производительности, вероятно, будет незначительной.

Однако я согласен с другими в том, что если он находится вне цикла, тело цикла выглядит чище.

Если есть вероятность, что вы когда-нибудь захотите продолжить обработку, а не выйти, если есть недопустимый номер, тогда вам нужно, чтобы код находился внутри цикла.

Если он внутри, то вы получите накладные расходы на структуру try / catch N раз, а не только один раз снаружи.

Каждый раз, когда вызывается структура Try / Catch, это увеличивает накладные расходы на выполнение метода. Просто немного тиков памяти и процессора, необходимых для работы со структурой. Если вы запускаете цикл 100 раз, и предположим, что стоимость составляет 1 тик на вызов try / catch, тогда использование Try / Catch внутри цикла будет стоить вам 100 тиков, а не только 1 тик, если он вне цикла.

Весь смысл исключений состоит в том, чтобы поощрять первый стиль: позволить объединить и обработать обработку ошибок один раз, а не сразу на каждом возможном месте ошибки.

положи внутрь. Вы можете продолжить обработку (если хотите) или создать полезное исключение, которое сообщает клиенту значение myString и индекс массива, содержащего неверное значение. Я думаю, что NumberFormatException уже скажет вам плохое значение, но принцип состоит в том, чтобы поместить все полезные данные в исключения, которые вы выбрасываете. Подумайте, что вам было бы интересно в отладчике на данном этапе программы.

Рассмотреть возможность:

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

В случае необходимости вы по достоинству оцените такое исключение, содержащее как можно больше информации.

Я хотел бы добавить свой собственный 0.02c о двух конкурирующих соображениях при рассмотрении общей проблемы размещения обработки исключений:

1. «Более широкая» ответственность блока try-catch (т.е. вне цикла в вашем случае) означает, что при изменении кода в какой-то более поздний момент вы можете по ошибке добавить строку, которая обрабатывается вашим существующим блоком catch; возможно непреднамеренно. В вашем случае это менее вероятно, потому что вы явно ловите NumberFormatException

2. Чем «уже» ответственность блока try-catch, тем сложнее становится рефакторинг. В частности, когда (как в вашем случае) вы выполняете «нелокальную» инструкцию из блока catch (оператор return null).

Это зависит от обработки сбоя. Если вы просто хотите пропустить элементы ошибки, попробуйте внутри:

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

В любом другом случае я бы предпочел попробовать на улице. Код читабельнее, чище. Может быть, было бы лучше выбросить исключение IllegalArgumentException в случае ошибки, вместо того, чтобы возвращать значение null.

Я вложу свои 0,02 доллара. Иногда вам нужно добавить «наконец» позже в свой код (потому что кто-нибудь когда-либо писал свой код идеально с первого раза?). В таких случаях внезапно становится более целесообразным иметь try / catch вне цикла. Например:

try {
    for(int i = 0; i < max; i++) {
        String myString = ...;
        float myNum = Float.parseFloat(myString);
        dbConnection.update("MY_FLOATS","INDEX",i,"VALUE",myNum);
    }
} catch (NumberFormatException ex) {
    return null;
} finally {
    dbConnection.release();  // Always release DB connection, even if transaction fails.
}

Потому что, если вы получите сообщение об ошибке или нет, вам нужно только один раз разорвать соединение с базой данных (или выбрать другой тип ресурса ...).

Другой аспект, не упомянутый выше, - это тот факт, что каждый try-catch имеет некоторое влияние на стек, что может иметь последствия для рекурсивных методов.

Если метод external () вызывает метод inner () (который может вызывать сам себя рекурсивно), попытайтесь найти try-catch в методе external (), если это возможно. Простой пример «сбоя стека», который мы используем в классе производительности, дает сбой примерно на 6400 кадрах, когда try-catch находится во внутреннем методе, и примерно на 11 600 кадрах, когда он находится во внешнем методе.

В реальном мире это может быть проблемой, если вы используете шаблон Composite и имеете большие сложные вложенные структуры.

Если вы хотите перехватить исключение для каждой итерации или проверить, на какой итерации выбрано исключение, и перехватить все исключения в итерации, поместите try ... catch внутри цикла. Это не прервет цикл, если возникнет исключение, и вы сможете перехватить каждое исключение в каждой итерации цикла.

Если вы хотите разорвать цикл и исследовать исключение при каждом вызове, используйте try ... catch out of the loop. Это прервет цикл и выполнит операторы после перехвата (если есть).

Все зависит от ваших потребностей. Я предпочитаю использовать try ... catch внутри цикла при развертывании, поскольку в случае возникновения исключения результаты не будут неоднозначными, и цикл не будет прерван и выполняться полностью.