Скала рассматривалась в первую очередь.
Сам язык понравился. Но с точки зрения новичков (и поэтому очень субъективно) не рискнули его использовать из-за:
— отсутствия в скале хорошой поддержки в ide (netbeans, eclipse);
— может из-за малого опыта, но «ручной» цикл сборки с помощью maven-a/sdb показался неудобным;
— явная типизация (всякие "_: _ => _") делали код в функциональном стиле очень громоздким;
— в самом языке не понравилось наличие большого количества сущностей.
Подпишусь под каждым словом. Просто нам повезло начать несколько проектов на clojure с нуля.
Т.к. людей в команде мало, тут не до «иллитизма». В начале на джаве было уютно: богатый фрэймворк, удобные IDE. Но пугал большой объем кода, требующийся иногда для простых вещей. А рефакторинг требовал много усилий.
Clojure позволил нам писать быстрее и короче не за счет синтаксического сахара и фреймворков с xml-ми, а просто за счет смены парадигмы программирования.
Даже тот пример с обработкой ошибок, который я привел, показателен. Для изменения паттерна достаточно изменить макрос. Изменения в коде, его использующем, если и будут, то будут в минимальном количестве. В джаве нам бы пришлось те изменения, которые мы внесли в макрос, применить в каждом коде с этим паттерном вручную.
В приведенном примере маппинга ошибок нижнего слоя в верхний нет.
Если уровень, например, процессинга оплаты, просто «оборачивает» ошибку, то он может заменить в InternalException текущий ErrorRef.ОШИБКа на соответствующий ОШИБКе ErrorRef, например на ErrorRef.PAYMENT_ERROR.
Если уровень обрабатывает ошибку, то он генеририрует новое исключение InternalException но уже со своим референсом ErrorRef.PAYMENT_ERROR.
В нашем случае, когда мы получим исключение на самом высоком уровне в виде «ошибка оплаты покупки», мы будем знать полный путь ошибки с контекстом (местро возникновения и ключевые параметры слоя) на каждом уровне, через который прошло исключение. Что может пригодиться, например, для понимания, какой из уровней был «виноват».
Обработки локально важна, т.к. смысловой контекст ошибки понятен именно на том уровне, где произошла исключительная ситуация. В моем случае этот контекст фиксируется и исключение выбрасываеся на уровень выше, где существует свой контекст. Эти контексты накапливаются и на самом высоком уровне могут быть использованы не только для просмотра цепочки и логгирования, но и для передачи в соответсвующий сервис обработки, например. Т.е., наоборот, мы ошибки локально не обрабатываем — только центрально.
Просто хотел показать на примере удобную возможность превращать повторный код в разных местах приложения, который нельзя реализовать в виде метода, в расширение языка.
Наверно пример можно было привести и более удачный. Буду благодарен, если подскажете лучшее решение по вопросу обработки ошибок в джаве.
Сам язык понравился. Но с точки зрения новичков (и поэтому очень субъективно) не рискнули его использовать из-за:
— отсутствия в скале хорошой поддержки в ide (netbeans, eclipse);
— может из-за малого опыта, но «ручной» цикл сборки с помощью maven-a/sdb показался неудобным;
— явная типизация (всякие "_: _ => _") делали код в функциональном стиле очень громоздким;
— в самом языке не понравилось наличие большого количества сущностей.
Т.к. людей в команде мало, тут не до «иллитизма». В начале на джаве было уютно: богатый фрэймворк, удобные IDE. Но пугал большой объем кода, требующийся иногда для простых вещей. А рефакторинг требовал много усилий.
Clojure позволил нам писать быстрее и короче не за счет синтаксического сахара и фреймворков с xml-ми, а просто за счет смены парадигмы программирования.
Даже тот пример с обработкой ошибок, который я привел, показателен. Для изменения паттерна достаточно изменить макрос. Изменения в коде, его использующем, если и будут, то будут в минимальном количестве. В джаве нам бы пришлось те изменения, которые мы внесли в макрос, применить в каждом коде с этим паттерном вручную.
Если уровень, например, процессинга оплаты, просто «оборачивает» ошибку, то он может заменить в InternalException текущий ErrorRef.ОШИБКа на соответствующий ОШИБКе ErrorRef, например на ErrorRef.PAYMENT_ERROR.
Если уровень обрабатывает ошибку, то он генеририрует новое исключение InternalException но уже со своим референсом ErrorRef.PAYMENT_ERROR.
Наверно пример можно было привести и более удачный. Буду благодарен, если подскажете лучшее решение по вопросу обработки ошибок в джаве.