2013-12-17 3 views
0

Я недавно разыскал ошибку, когда список был длиной 0, но попытка доступа была сделана в положении 1Следует ли проверять IndexOutOfBoundsException?

System.out.println("key is " + keyValuesPairs.get(0)+ " , value is " + keyValuesPairs.get(1)); 

Это вызвало IndexOutOfBoundsException, но так как он не был пойман исключение молча упало и никаких признаков не является сделал исключение. По этой причине должно быть исключено IndexOutOfBoundsException, поскольку это может вызвать затруднения в обнаружении ошибок?

Обновление: исключение не отключено.

+4

Если вы это заметили, что бы вы сделали? –

+0

Беззвучно упал с какого звонка? Ajax, EJB? – falsarella

+2

Зачем это было тихо опущено? Непроверенные исключения должны быть выровнены и создавать трассировки стека. –

ответ

5

Ваша проблема не Должен ли я поймать это исключение? Это Почему это исключение потребляется без сообщения?.

В коде действительно есть ошибка, но другая ошибка - скрытая, которая тихо поглощает ваше исключение и отбрасывает ее - гораздо более пагубная ошибка.

Вот почему

... 
} catch (Exception e) { 
    // Ignore it. 
} 

является почти всегда код запах.

+1

Обратите внимание, что просто _logging_ также игнорирует его. –

+1

@SotiriosDelimanolis - Записывать его, не решая его. –

2

Нет, я не должен быть пойман. Это исключение во время выполнения этой ссылки для получения более подробной информации: http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html

Что вы можете сделать, это тестирование по индексу используется против длины массива

1

Я бы не поймать это исключение. Вместо этого я бы просто проверить границы, как это:

if(keyValuesPairs.size() > 0) {...} 
0

Не следует проверять, потому что если он будет проверен, то интерфейс List и другие должны быть изменены, чтобы добавить throws в методы, которые были бы излишними.

Исключения, такие как IndexOutOfBoundsException или NullPointerException, должны быть предотвращены до их выброса. Эти исключения: RuntimeException, которые могут возникнуть, когда приложение запускается в зависимости от данных, а не умышленно. Обстоятельства, в которых происходят эти исключения, непредсказуемы и не могут сказать, генерирует ли код исключение или нет. Вот почему это должны быть исключения во время выполнения.

В вашем коде, чтобы быть допустимым кодом, вы должны проверить границы индекса, прежде чем использовать произвольный индекс для доступа к элементам списка. Используйте isEmpty() или size(), чтобы получить условие, в котором вы должны исправить поток.

1

Вы уже ответили на вопрос:

«Я недавно выследили ошибка, когда список был длиной 0, но попытка доступа была сделана в положении 1.»

Это ошибка в коде - вам нужно решить проблему, когда это возможно даже для индекса, большего, чем массив. Причина в том, что это исключение не проверено (это означает, что Java не требует, чтобы вы его поймали). И причина в том, что вы не можете знать, почему неправильный индекс использовался при возникновении ошибки и не может изящно восстановить его.

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

1

Все RuntimeException s - это то, что идеально, никогда не должно произойти. Они вызваны, когда программа недостаточно осторожна в отношении неизвестного и пытается делать то, что никогда не следует рассматривать никаким здравомыслящим методом, а с объектами и методами у них есть только мельчайший проблеск.

Иногда метод невольно обманывается в попытке чего-то, чего он не должен, гнусным мастером, который заставляет их принимать null или пустой массив, даже несмотря на то, что в документации по методу указывается, что он неквалифицирован для обработки таких вещей. Но еще хуже, когда мастер получает слово, что их схемы потерпели неудачу, некоторые попытаются скрыть свой провал, перехватив исключение, прежде чем он сможет достичь своего начальства, развращая систему ленинностью и неряшливостью. Даже когда мастер имеет подходящий способ справиться с их провалом, они по-прежнему тратят лишние ресурсы и вычислительную мощность, вызванные беспорядком.

Мораль истории: не писать плохой код.

Смежные вопросы