Не уверен, что это хорошая рекомендация.
В реальном проекте конкретные языковые фичи будут использоваться в 1%-3% строках кода. Т.е. либо обучающийся не будет читать оcтальные 97%-99% (тогда непонятно зачем их писать), либо будет читать (тогда из каждого часа обучающийся посвятит фичам 1-2 минуты).
Пример: для изучения написания своего загрузчика классов читать сорцы RMI (remote class loading) + сорцы Tomcat (множественные загрузчики классов).
>> — Так вы же пишете учебные статьи, поэтому и появляются дополнения. Мы знаем, что не стоит строить логику на исключениях, а разработчик, только столкнувшийся с Java, прочитав вашу статью, может и не узнать об этом.
— В этом смысле — все правильно. Но я стараюсь написать то, или структурировать материал так, чего/как нет в «классических» книгах: Хорстманн, Эккель, Гослинг, Шилдт.
Т.е. я сам свой материал рассматриваю как некоторое дополнение, а не единственный источник знаний.
Ислючения — механизм для «особенных ситуаций». Не стоит строить логику работы на исключениях.
PlayFramework — из мира Scala. Этот язык не везде идеально ложится на JVM, отмеченный Вами момент так же (кажется) есть у встроенных в Scala акторов (реализация выхода из замыкания через бросок исключения, если я правильно выражаюсь).
— Я полностью согласен с тем, что исключения не самый быстрый механизм работы. И что есть способы его ускорить, но такие указания для «неокрепших умов» могут толкнуть на нетипичный дизайн кода (есть отличие в том как писать методички и как писать справочники, это — скорее методичка).
— На замечание по поводу PlayFramework — спасибо, не знал. Вы могли бы кинуть кусок кода или ссылку, где можно больше прочитать про API рендеринга?
Господи, да что же все так привязались к медленно работе исключений?
Сколько же раз у вас бросается исключений в секунду? 1.000, 10.000, 100.000 в секунду?
Переписывайте такой код!
В нормальном коде не более 10-100 бросков в секунду.
1. SRP говорит, что одна сущность (метод, поле, класс, ...) отвечает за что-то одно.
У меня же одно конкретное действие (захват USB-порта) может не сработать по разным причинам.
Эти причины — и есть исключительные ситуации.
На вскидку не чувствую, что надо перепроектировать этот метод.
Хотя можно, конечно, ввести много фаз подключения (поиск порта, проверка на подходящую версию, проверка на инициированность), но если вам дали такое нижестоящее API (которое делает соединение одним махом на уровне ОС), то вы искусственно породите множество классов-состояний проверки порта. И за вами придет Бритва Оккама.
И тогда решайте, что вам дороже — SRP или Оккам:)
2. Возможно это Facade к сложному многостадийному API с исключение на каждую фазу. Тогда Facade уменьшает кол-во вызовов и классов, но собирает в пучек все исключения.
В большинстве случаев (но не во всех) можно устранить
NullPointerException — можно проверить на null
IllegalStateException — вызвал метод у объекта в ненадлежащем состоянии, значит давай объект в корректном состоянии
ConcurrentModificationException — случайно изменил коллекцию с используемым итератором
…
>> Мне хочется понять это я что-то недопонимаю или это так и надо и все к этому приходят?
В моем представлении, при использовании проверяемых исключений
1. Мы подключаем компилятор, переходим к статически типизированному стилю Java. Требуем, что бы компилятор следил за наличием обработчиков.
2. Можем обезопасить себя, как разработчики сервисных модулей. При вызове на ковер к начальству с вопросом «почему ваша программа не нашла USB порт, но не уведомила пользователя об этом», вы говорите
— Товарищи, мой код
И обнаруживает, что USB нет И кидает USBNotFounException И это исключение проверяемое, значит тот, кто вызывает этот метод получил USBNotFounException (где-то обязательно есть catch), но неправильно отреагировал.
Если бы это был unchecked исключение, то клиент может все списать на недостатки коммуникации в команде, типа, «ну я недопонял, что такое может быть», «а ты меня явно предупредил о такой ситуации»,… А так, за вас говорит компилятор.
ЕСЛИ будет, то план такой:
1. try+catch+finally
2. checked/unchecked
3. «внутренности исключения» и 4 наиболее популярных стратегии обработки
4. Изменения в Java 7 (try-with-resources, multicatch, more precise rethrow)
5. 25 наиболее популярных исключения в Java (от ArithmeticException до UnsupportedOperationException)
>> Конструкции, что в конце статьи приведены где-то применяются на практике? Я имею в виду это считается нормальным стилем?
именно в таком виде — нет.
но
1. Это учебные примеры, задача которых состоит в том, что бы слушатель досконально разобрался с механизмами обработки исключений. Тройные циклы и тройные if — это тоже ненормально.
2. Косвенным образом вложенные конструкции присутствуют постоянно. Вы под try-catch-ем вызываете метод в котором тоже есть try-catch.
Да, это — поле класса.
Момент инициализации определяется по спецификации языка. Там не все просто, надо вчитываться. Ссылку на соответствующий раздел спеки я давал в комментариях.
В конкретном случае — в момент вызова метода, я приводил в комментариях пример кода и его вывода. Посмотрите.
class Test {
public static void main(String[] args) {
System.err.println("Hello!");
System.err.println(Something.getInstance());
}
}
>> Hello!
>> Exception in thread "main" java.lang.Error
>> ...
Т.е. исключение (и инициализация экземпляра) происходит при вызове метода getInstance, не ранее (мы успеваем вывести «Hello!»).
В реальном проекте конкретные языковые фичи будут использоваться в 1%-3% строках кода. Т.е. либо обучающийся не будет читать оcтальные 97%-99% (тогда непонятно зачем их писать), либо будет читать (тогда из каждого часа обучающийся посвятит фичам 1-2 минуты).
Пример: для изучения написания своего загрузчика классов читать сорцы RMI (remote class loading) + сорцы Tomcat (множественные загрузчики классов).
Аннотации в Java, часть I
Введение в Акторы на основе Java/GPars, Часть I
1000+ часов видео по Java на русском
JSR 133 (Java Memory Model) FAQ
Программирование-по-Контракту в Java
Исключения в Java, Часть I (try-catch-finally)
Исключения в Java, Часть II (checked/unchecked)
Скорее просто хотелось продемонстрировать try-with-resources (это таки лабораторная, а не библиотека).
— В этом смысле — все правильно. Но я стараюсь написать то, или структурировать материал так, чего/как нет в «классических» книгах: Хорстманн, Эккель, Гослинг, Шилдт.
Т.е. я сам свой материал рассматриваю как некоторое дополнение, а не единственный источник знаний.
PlayFramework — из мира Scala. Этот язык не везде идеально ложится на JVM, отмеченный Вами момент так же (кажется) есть у встроенных в Scala акторов (реализация выхода из замыкания через бросок исключения, если я правильно выражаюсь).
— Я полностью согласен с тем, что исключения не самый быстрый механизм работы. И что есть способы его ускорить, но такие указания для «неокрепших умов» могут толкнуть на нетипичный дизайн кода (есть отличие в том как писать методички и как писать справочники, это — скорее методичка).
— На замечание по поводу PlayFramework — спасибо, не знал. Вы могли бы кинуть кусок кода или ссылку, где можно больше прочитать про API рендеринга?
Сколько же раз у вас бросается исключений в секунду? 1.000, 10.000, 100.000 в секунду?
Переписывайте такой код!
В нормальном коде не более 10-100 бросков в секунду.
Есть такая беда, не могу исправить:(
Исключения в Java, Часть II (checked/unchecked)
Исключения в Java, Часть I (try-catch-finally)
Введение в Акторы на основе Java/GPars, Часть I
Аннотации в Java, часть I
или делаю переводы
Программирование-по-Контракту в Java
JSR 133 (Java Memory Model) FAQ (перевод)
или классификации/подборки
1000+ часов видео по Java на русском
Ну а рабочие материалы текущих курсов, значит, выкладывать не буду.
А то все становится слишком сложным для меня.
— Буду считать это провальной пиар-акцией.
Как понимаю, получим инвестиций 60млн баксов они с трудом отбили 5.
Так что — не планирую.
Прошло уже 5 семинаров из 16, но всю информацию я выдаю в закрытом доступе.
У меня же одно конкретное действие (захват USB-порта) может не сработать по разным причинам.
Эти причины — и есть исключительные ситуации.
На вскидку не чувствую, что надо перепроектировать этот метод.
Хотя можно, конечно, ввести много фаз подключения (поиск порта, проверка на подходящую версию, проверка на инициированность), но если вам дали такое нижестоящее API (которое делает соединение одним махом на уровне ОС), то вы искусственно породите множество классов-состояний проверки порта. И за вами придет Бритва Оккама.
И тогда решайте, что вам дороже — SRP или Оккам:)
2. Возможно это Facade к сложному многостадийному API с исключение на каждую фазу. Тогда Facade уменьшает кол-во вызовов и классов, но собирает в пучек все исключения.
NullPointerException — можно проверить на null
IllegalStateException — вызвал метод у объекта в ненадлежащем состоянии, значит давай объект в корректном состоянии
ConcurrentModificationException — случайно изменил коллекцию с используемым итератором
…
В моем представлении, при использовании проверяемых исключений
1. Мы подключаем компилятор, переходим к статически типизированному стилю Java. Требуем, что бы компилятор следил за наличием обработчиков.
2. Можем обезопасить себя, как разработчики сервисных модулей. При вызове на ковер к начальству с вопросом «почему ваша программа не нашла USB порт, но не уведомила пользователя об этом», вы говорите
— Товарищи, мой код
И обнаруживает, что USB нет И кидает USBNotFounException И это исключение проверяемое, значит тот, кто вызывает этот метод получил USBNotFounException (где-то обязательно есть catch), но неправильно отреагировал.
Если бы это был unchecked исключение, то клиент может все списать на недостатки коммуникации в команде, типа, «ну я недопонял, что такое может быть», «а ты меня явно предупредил о такой ситуации»,… А так, за вас говорит компилятор.
1. try+catch+finally
2. checked/unchecked
3. «внутренности исключения» и 4 наиболее популярных стратегии обработки
4. Изменения в Java 7 (try-with-resources, multicatch, more precise rethrow)
5. 25 наиболее популярных исключения в Java (от ArithmeticException до UnsupportedOperationException)
но не понимаю — какой в этом смысл.
именно в таком виде — нет.
но
1. Это учебные примеры, задача которых состоит в том, что бы слушатель досконально разобрался с механизмами обработки исключений. Тройные циклы и тройные if — это тоже ненормально.
2. Косвенным образом вложенные конструкции присутствуют постоянно. Вы под try-catch-ем вызываете метод в котором тоже есть try-catch.
На второй лекции разберем:
Момент инициализации определяется по спецификации языка. Там не все просто, надо вчитываться. Ссылку на соответствующий раздел спеки я давал в комментариях.
В конкретном случае — в момент вызова метода, я приводил в комментариях пример кода и его вывода. Посмотрите.
Т.е. исключение (и инициализация экземпляра) происходит при вызове метода getInstance, не ранее (мы успеваем вывести «Hello!»).