напиши первым
Недавно автор пишет учебник по сочетанию JavaWeb и автоматизации.Запись последней статьи находится по адресуздесь, второй еще в разработке, перед публикацией обсудим важный навык Java, Exception.
Достижение работы программы — это то, к чему стремятся все младшие программисты,Thinking in JavaПоэтому она стала очень подходящей книгой для начала работы, однако по мере накопления количества строк кода будет следовать все больше и больше ям. В настоящее время особенно важно более глубокое понимание основ. В приложении JavaWeb и автоматизации создание исключений без размышлений приведет к избыточности и слабости кода.Эта статья, опубликованная сегодня, будет тщательно анализировать применение исключений.
Следует отметить, что эта статьяНе объяснять основы того, как генерировать исключенияНужно, чтобы читатели имели определенное представление о механизме ИСКЛЮЧЕНИЙ, а некоторые примеры из текста взяты изEffective Java, вот в то же время рекомендую эту книгу читателям как важный инструмент для Java advanced, в приложении в конце статьи для справки есть англоязычные примечания автора части Exception.
Сценарии с использованием исключения
Не используйте Exception в итерационных циклах, особенно с использованием ArrayIndexOutOfBounds, например:
try {
int i = 0;
while(true)
array[i++].doSomething();
} catch(ArrayIndexOUtOfBoundsException e) {
}
Главным образом потому, что в настоящее время использование try-catch имеет три очевидных недостатка:
- Это противоречит принципу настройки обработки исключений JVM, JVM потратит больше времени на обработку.
- Помещение кода в инструкцию try-catch отключает некоторые оптимизации среды выполнения JVM.
- Оптимизирован канонический итеративный метод записи. Благодаря внутренней обработке JVM удается избежать многих избыточных механизмов проверки, и это более подходящий выбор.
Если мы вызовем другой массив в операторе try-catch, и в этом массиве возникнет исключение ArrayIndexOutOfBounds, ошибка будет ослеплена исключением catch. Напротив, стандартный метод итеративной записи вовремя прекратит выполнение потока, сообщит об ошибке и предоставит путь для отслеживания ошибки, чтобы программисту было легче найти источник ошибки.
Теперь давайте взглянем на стандартный итеративный метод записи через интерфейс Java Iterator.В стандартном итеративном методе записи мы используем hasNext() в качестве метода проверки состояния для реализации зависящего от состояния метода next(). следует:
for (Iterator<Foo> i = collection.iterator(); i.hasNext(); ) {
Foo foo = i.next();
//...
}
Подводя итог, Exception подготовлен для исключений или исключительных ситуаций и не должен использоваться в обычных операторах, и программисты не должны писать API, которые заставляют других использовать Exception в операторах обычного потока.
Разница между проверенным и непроверенным
Throwable является родительским классом для Exception и Error в Java, а вEffective JavaВ книге Throwable делится на следующие три категории:
- Checked Exceptions
- Runtime Exceptions
- Errors
Среди них 2 и 3 являются Unchecked Throwable, поэтому, когда мы анализируем классы исключений Java, будет понятнее анализировать с двух логических точек зрения Checked и Unchecked.
Checked Exception относится к тем, которые проверяются во время компиляции, и такие ошибки «исправимы» во время выполнения. Их нужно выбрасывать при написании программ, то есть эти исключения не должны быть вызваны программистами, а аналогичны "рутинным проверкам".
Наоборот, Runtime Exception относится к ошибкам, допущенным самими программистами, в первой части статьи мы четко указали, что такие ошибки не должны выбрасываться, а должны исправляться самими программистами. Следует отметить, что, как правило, Exception, разработанное нами, должно использоваться как прямой или косвенный подкласс Runtime Exception. Если у вас поверхностное представление об Exception и яростно запоминаете подкласс Runtime Exception, это также очень полезно для отладки, и вы можете быстро найти проблемы в коде.
Ошибки отличаются от исключений. Они связаны с JVM. Когда вы видите переполнение стека при написании алгоритма, это не ваше понимание языка приводит к тому, что ваш код имеет лазейки, а ваша структура данных, которая делает JVM нехватка ресурсов или инвариантные сбои делают программу неспособной продолжать выполнение, поэтому, когда мы видим ошибки, мы не должны их выбрасывать, а должны изменить структуру кода.
Таким образом, если его можно восстановить в работе, мы должны выдать это проверенное исключение. Выдает исключение времени выполнения, когда неясно, что делать. Важно не определять Throwable, который не является ни подклассом Checked Exception, ни подклассом Runtime Exception, и не забудьте добавить методы к вашему собственному Checked Exception, чтобы код мог восстанавливаться на лету.
Как использовать проверенное исключение
Мы часто сталкиваемся с такой проблемой: в методе есть строка кода, которая должна генерировать Exception, и нам нужно обернуть ее в оператор try-catch. После Java8 нам приходится выбрасывать это исключение при использовании этого API, что сильно снижает качество нашего кода.
Вероятно, самый простой способ решить эту проблему — запустить этот метод без возврата какого-либо значения, но если мы это сделаем, у нас будет намного меньше шансов вернуть информацию и данные с помощью этого метода.
Поэтому мы предлагаем другое решение, которое состоит в том, чтобы сделать его непроверенным исключением, разделив метод, который должен генерировать проверенное исключение, на два метода. Первый метод указывает, следует ли вызывать исключение, возвращая логическое значение, а второй делает все остальное. Ниже приведен простой пример трансформации.
Заявление, завернутое в try-catch:
try {
ted.read(book);
} catch (CheckedException e) {
//...do sth.
}
Вот измененный код:
if (ted.understand(book)) {
ted.read(book);
} else {
//...do sth.
}
Проще говоря, изначально метод «чтения» Теда был для выдачи исключения о том, что он не может прочитать книгу, но мы разделили его на два метода «понимание» и «чтение», чтобы восстановить его, чтобы избежать использования try -ловить.
В общем, рефакторинг Checked Exception должен сделать код более лаконичным и надежным, а также избежать чрезмерного использования Checked Exception, потому что чрезмерное использование сделает API очень недружественным для пользователей. Столкнувшись с вышеупомянутой ситуацией, сначала подумайте, использовать ли метод с нулевым возвращаемым значением, потому что это самое прямое и простое решение.
Предпочитаю исключение из стандартной библиотеки
В библиотеке Java есть три основных преимущества использования Exception:
- Упростите изучение и использование своего API, поскольку большинство программистов понимают стандартные исключения.
- Упростите чтение программ, использующих ваш API
- Используйте меньше памяти и быстрее загружайте классы (JVM)
Не используйте родительские классы Exception, RuntimeException, Throwable или Error напрямую.Часто используемые исключения перечислены в следующей таблице.
| Exception | сцены, которые будут использоваться |
|---|---|
| IllegalArgumentException | Непревзойденная передача ненулевых аргументов |
| IllegalStateException | Неинициализированный объект (несоответствие состояния объекта) |
| NullPointerException | Неожиданно обнаружен нулевой указатель |
| IndexOutOfBoundsException | индексный параметр вне допустимого диапазона |
| ConcurrentModificationException | Несколько потоков изменяют один и тот же объект |
| UnsupportedOperationException | Этот объект не поддерживает ссылку на этот метод |
Следует отметить, что повторно используемое исключение должно соответствовать семантике записи, как подробно описано в документации, а не просто соответствовать имени исключения.
Эпилог
В дополнение к пунктам, подробно изложенным выше, важно отметить, что, прежде всего,Исключения, создаваемые каждым методом, должны быть задокументированы.. Второй,сохранить атомарное исключение. самое главное,Никогда не игнорируйте пойманные исключения в catch.
Для многих обработка исключений — это просто Alt+Enter, но часто это вызывает головную боль на этапе оптимизации кода. Я надеюсь, что эта статья вдохновит вас и поможет лучше понять некоторые коды из следующих руководств. , Задавайте вопросы и совершенствуйтесь вместе.
приложение:Effective Javaучебные заметки
Chapter 10 EXCEPTIONS
Item 69: Use exceptions only for exceptional conditions
Do not use try catch to handle your loop, it might mask the bug and is also very slow.
Exceptions are, as their name implies, to be used only for exceptional conditions; they should never be used for ordinary control flow and do not write APIs that force others to do so.
A well designed API must not force its clients to use exceptions for ordinary control flow.
In iteration codes, one should use hasNext() to decide the life circle of a loop.
Item 70: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors
Use checked exceptions for conditions from which the caller can reasonably be expected to recover.
Use runtime exceptions to indicate programming errors.
All of the unchecked throwables you implement should subclass RuntimeException (directly or indirectly).
Don't define any throwables that are neither checked exceptions nor runtime exceptions.
Provide methods on your checked exceptions to aid in recovery.
Item 71: Avoid unnecessary use of checked exceptions
In Java 8, methods throwing checked exceptions can't be used directly in streams.
How to solve the problem that if a method throws a single checked exception, this exception is the sole reason the method must appear in a try block and can't be used directly in streams?
The easiest way to eliminate this is to return an optional of the desired result type.
You can also turn a checked exception into an unchecked exception by breaking the method that throws the exception into two methods, the first of which returns a boolean indicating whether the exception would be thrown.
Item 72: Favor the use of standard exceptions
The Java libraries provide a set of exceptions that covers most of the exceptions-throwing needs of most APIs.
Benefits: makes your API easier to learn because it matches the established conventions, makes programs using your API easier to read, a smaller memory footprint and less time spent loading classes.
Do not reuse Exception, RuntimeException, Throwable, or Error directly.
Reuse must be based on documented semantics, not just on name.
Item 73: Throw exceptions appropriate to the abstraction
Higher layers should catch lower-level exceptions and, in their place, throw exceptions that can be explained in terms of the higher-level abstraction, aka. Exception Translation.
While exception translation is superior to mindless propagation of exceptions from lower layers, it should not be overused.
If it is not feasible to prevent or to handle exceptions from lower layers, use exception translation, unless the lower-level method happens to guarantee that all of its exceptions are appropriate to the higher level.
Item 74: Document all exceptions thrown by each method
Always declare checked exceptions individually, and dovument precisely the conditions under which each one is thrown using @throws tag.
Use the Javadoc @throws tag to document each exception that a method can throw, but do not use the throws keyword on unchecked exceptions.
If an exception is thrown by many methods in a class for the same reason, you can document the exception in the class's documentation comment.
Item 75: Include failure-capture information in detail messages
To capture a failure, the detail message of an exception should contain the values of all parameters and fields that contributed to the exception.
Do not include passwords, encryption keys, and the like in detail messages.
Item 76: Strive for failure atomicity
A failed method invocation should leave the object in the state that it was in prior to the invocation.
Item 77: Don't ignore exceptions
An empty catch block defeats the purpose of exceptions.
If you choose to ignore an exception, the catch block should contain a comment explaining why it is appropriate to do so, and the variable should be named ignored.