Хороший способ выполнения общих блоков кода в том же контексте обертки, поддерживающий java.lang.Exception без параметров ввода/вывода?
Я искал такое решение:
(более подробно: для некоторого плагина maven, выполняющего другой код сборки в несколько этапов/целей):
void foo() {
execCode( () -> doBar() ) ;
execCode( () -> new File("/baz.txt").create() ) ;
execCode( () -> {
System.out.println( "test" ) ;
throw new MojoFailureException("problem 1") ;
}) ;
}
void execCode( Code code ) throws MojoFailureException {
try {
// ... some common initialization / param parsing here ...
code.run() ;
} catch( Exception e ) {
// ... common exception handling throwing e.g. MojoFailureException ...
}
}
поддержка (в первую очередь (Э), (ГРАММ) и (С) ниже):
- (Э): код блокирует выдачу любых
java.lang.Exception - (В): не требуются входные и выходные значения/объекты
- (С): короткий, простой для чтения/записи код (минимальный беспорядок)
- также избегать предупреждений IDE и работать с ними (например, с помощью
@Ignoreдля неиспользуемых параметров универсального типа)
- также избегать предупреждений IDE и работать с ними (например, с помощью
- (8): поддержка Java 8+
- (л): никаких дополнительных зависимостей lib/jar, если это возможно (также подойдут очень распространенные, такие как Google Guava или Apache Commons)
- (ГРАММ): общий контекст (например, некоторые задачи сборки), где можно просто знать, что что-то должно/будет сделано, но должна быть инкапсулирована правильная обработка исключений и другие вещи (общие для каждого вызова).
Ответы 1
Коротко о наилучшей найденной стратегии:
import java.util.concurrent.Callable;
// ...
void foo() {
execCode( () -> doBar() ) ;
execCode( () -> 5 + 2 ) ;
execCode( () -> { System.out.println( "test" ) ; return 0 ; }) ;
}
void execCode( Callable<Object> code ) {
try {
code.call() ;
} catch( Exception e ) {
// ...
}
}
подробнее:
решения частично найден в других ответах и их недостатки выше:
- (SL): использование
java.util.concurrent.Callable(решение выше)- соответствует всем вышеперечисленным требованиям
- также будет хорошо работать с некоторым возвращаемым значением, если это необходимо
- (С.Ф.): с использованием
java.util.Function- не поддерживает (Э)
- особенно с (В) это больше беспорядка ((С)) и семантически запутанно
- например
void foo() { execCode( (i) -> doBar() ) ... void execCode( Function< Void, Void > code ) { ... code.apply( null ) ... } - см. также этот ответ
- (СИ): создание некоторого обычай
interface(класс) для его выполнения- противоречит (С)
- например
interface Code { abstract void run() throws Exception; } - см. также этот ответ
- (СМ): использование ссылок на методы, таких как
this::doBar- особый случай, который может быть очень коротким и элегантным, если код (уже) в методе некоторых объектов способствует (С)
- будет работать с
execCode( Callable<Object> ... ) { ... } - но не с
execCode( Runnable ... ) { ... }- противоречит (Э)
- см. также этот ответ
- (SR): использование
java.lang.Runnable- противоречит (Э) и, следовательно, (С), поскольку это позволяет выбрасывать только
RuntimeException, но не проверенные - см. также этот ответ
- противоречит (Э) и, следовательно, (С), поскольку это позволяет выбрасывать только
- (ЮАР): использование
java.lang.AutoCloseable- он соответствует требованиям (Э), (В) и (л), но нуждается хотя бы в некоторых комментариях, чтобы объяснить, почему есть
execCode( AutoCloseable code ) { ... code.close() ; ... }, хотя код не должен ничего делать с семантическим закрывающим контекстом :)
- он соответствует требованиям (Э), (В) и (л), но нуждается хотя бы в некоторых комментариях, чтобы объяснить, почему есть
- (SC): использование
java.util.function.Consumer- не поддерживает (Э)
- см. также этот ответ* (С.Х): использование
java.lang.reflect.Method - противоречило бы особенно (С)
- см. также этот ответ
- (С.7): решение шаблон команды
- если он должен быть совместим с Java 7 (противоречит (8)), этот ответ с шаблоном команды может быть хорошим решением
@Holger хорошо, но это не преимущество / решение для основных требований, особенно потому, что (ГРАММ), а также (Э) не покрыты. (эти execCode( ...) звонки бывают не только в foo() { ... }!)
Я просто имею в виду ваш собственный пример; вместо execCode( () -> { System.out.println( "test" ) ; return 0 ; }) ; можно написать execCode(Executors.callable(() -> System.out.println( "test" ))); Это просто дополнение, а не решение само по себе. Конечно, когда речь идет о проверенных исключениях, можно и нужно прибегать к { statement; return null; }. Кстати, для void также есть функциональный интерфейс, позволяющий генерировать исключения, AutoCloseable, но, возможно, его использование для действий общего назначения может ввести читателя в заблуждение.
@Holger return 0 просто указывает, что могут быть произвольные большие блоки кода с несколькими операторами. относительно AutoClosable :) разве вы не видели решение (ЮАР), в котором это точно упоминается?
Нет, я не видел. В этом списке легко что-то упустить из виду, поскольку в нем излишне многословно обсуждаются нерешенные вопросы. Например, зачем долго обсуждать java.util.Function, java.lang.Runnable и java.util.function.Consumer, если они не используются из-за отсутствия поддержки исключений? Почему «использование ссылок на методы» вообще рассматривается как решение? Разницы между () -> doBar() и this::doBar нет, работает ли она, зависит от функционального интерфейса.
@Holger: если ты не хочешь что-то/кого-то понять, я ничего не могу с собой поделать. Все они являются решениями очень распространенной и общей проблемы, предложенной в списке, и различными решениями. Поиск в Интернете и нахождение такой сжатой информации, как здесь, гораздо более ценно, чем сосредоточение внимания на крошечных различиях одного и того же вопроса. Лучшими ответами для меня и, вероятно, для других являются те, которые не только исправляют мои, возможно, неправильные строки кода, но и исправляют мое мышление о самой проблеме и видение ее в более широком масштабе. Но я согласен, что это мышление не применяется большинством.
@Holger: есть разница между () -> doBar() и this::doBar. если вы не знаете, это не значит, что его нет :) попробуйте, как я описал выше, и вы не сможете скомпилировать последний. вы отвечаете на то, чего точно не знаете :-(
«если вы не знаете, это не значит, что его нет». Почему бы вам не просветить нас и рассказать разницу (относящуюся к вашему ответу), о существовании которой вы утверждаете? Ваш «пример» — это просто неполный код, даже синтаксис, указанный в вашем ответе (this::doBar()), неверен. Легко показать, что () -> doBar() и this::doBar работают одинаково хорошо, ideone.com/ftWzfl Если это не соответствует вашему варианту использования, это проблема вашего неполного «примера».
Давайте продолжить обсуждение в чате.
Вы также можете написать
execCode(Executors.callable(() -> System.out.println( "test" )));