Предпочитайте стандартные исключения

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

Повторное использование уже имеющихся исключений имеет несколько преиму­ществ. Главное то, что они упрощают освоение и применение вашего API, поскольку соответствуют установленным соглашениям, с которыми программисты уже знакомы. С этим же связано второе преимущество, которое заключается в том, что программы, использующие ваш API, легче читать, поскольку там нет незнакомых, сбивающих с толку исключений. Наконец, чем меньше классов исключений, тем меньше требуется места в памяти и времени на их загрузку.

Чаще всего используется исключение IllegalArgumentException. Обычно оно инициируется, когда вызываемому методу передается аргумент с неправильным зна­чением. Например, IllegalArgumentException может инициироваться в случае, если для параметра, указывающего количество повторов для некоей процедуры, передано Отрицательное значение.

Другое часто используемое исключение - IllegalStateException. Оно обычно инициируется, если в соответствии с состоянием объекта вызов метода является непра­вомерным. Например, это исключение может инициироваться, 'Когда делается попытка использовать некий объект до его инициализации надлежащим образом.

Вряд ли можно утверждать, что все неправильные вызовы методов сводятся к не­прав ильным аргументам или неправильному состоянию, поскольку для определенных типов неправильных аргументов и состояний стандартно используются совсем другие

165

исключения. Если при вызове какому-либо параметру было передано null, тогда как значения null для него запрещены, то в этом случае в соответствии с соглашениями должно инициироваться исключение NullPointerException, а не IllegalArgument­Exception. Точно так же, если параметру, который соответствует индексу не коей последовательности, при вызове было передано значение, выходящее за границы до­пустимого диапазона, инициироваться должно исключение IndexOutOfBoundsException, а не IllegalArgumentException.

Еще одно универсальное исключение, о котором необходимо знать: Concurrent­ModificationException. ()но должно инициироваться, когда объект, предназначав­шийся для работы в одном потоке или с внешней синхронизацией, обнаруживает, что его изменяют (или изменили) из параллельного потока.

Последнее универсальное исключение, заслуживающее упоминания,- Unsupported­OperationException. ()но инициируется, если объект не имеет поддержки произво­димой операции. По сравнению с другими исключениями, обсуждавшимися в этой статье, UnsupportedOperationException применяется довольно редко, поскольку боль­шинство объектов обеспечивает поддержку всех реализуемых ими методов. Это иск­лючение используется при такой реализации интерфейса, когда отсутствует поддержка одной или нескольких заявленных в нем дополнительных функций. Например, реали­зация интерфейса List, имеющая только функцию добавления элементов, будет ини­циировать это исключение, если кто-то попытается удалить элемент.

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

Часто используемые исключения

Исключение	Повод для использования
IllegalArgumentException	Неправильное значение параметра
IllegalStateException	Состояние объекта неприемлемо для вызова метода
NullPointerException	Значение параметра равно null, а это запрещено
IndexOutOfBoundsException	Значение параметра, задающего индекс, выходит за пределы диапазона
ConcurrentModificationException	Обнаружена параллельная модификация объекта из разных потоков, а это запрещено
UnsupportedOperationException	Объект не имеет поддержки указанного метода

Помимо перечисленных исключений, при определенных обстоятельствах могут применяться и другие исключения. Например, при реализации таких арифметических объектов, как комплексные числа и матрицы, уместно пользоваться исключениями ArithmeticException и NumberFormatException. Если исключение отвечает вашим

166

потребностям - пользуйтесь им, но только чтобы условия, при которых вы будете его инициировать, не вступали в противоречие с документацией к этому исключению. Выбирая исключение, следует исходить из его семантики, а не только из названия. Кроме того, если вы хотите дополнить имеющееся исключение информацией об отказе (статья 45), не стесняйтесь создавать для него подклассы.

И наконец, учитывайте, что выбор исключения - не всегда точная наука, по­скольку "поводы для использования", приведенные в таблице 8.1, не являются взаи­моисключающими. Рассмотрим, например, объект, соответствующий колоде карт. Предположим, что для него есть метод, осуществляющий выдачу карт из колоды, причем в качестве аргумента ему передается количество требуемых карт. Допустим, что при вызове с этим параметром было передано значение, превышающее количество карт, оставшихся в колоде. Эту ситуацию можно толковать как IllegalArgument­Exception (значение параметра "размер сдачи" слишком велико) либо как IllegalStateException (объект "колода" содержит слишком мало карт для обработки запроса). В данном случае, по-видимому, следует использовать IllegalArgumentException, но непреложных правил здесь не существует.