совет по вложенным бутербродам с кодом попытки / наконец-то на Java

Это мило.

Никаких серьезных жалоб, мелочи не у меня в голове:

• небольшая нагрузка на производительность
• вам нужно сделать некоторые вещи final, чтобы Компенсация их увидела. Возможно, это предотвращает некоторые варианты использования
• вы должны перехватывать исключения во время компенсации и продолжать выполнение компенсаций, несмотря ни на что.
• (немного надумано) вы можете случайно очистить очередь компенсации во время выполнения из-за ошибки программирования. Ошибки программирования OTOH могут произойти в любом случае. А с вашей очередью компенсации вы получаете «условные окончательные блоки».
• не заходите слишком далеко. В рамках одного метода это кажется нормальным (но тогда вам, вероятно, все равно не понадобится слишком много блоков try / finally), но не передавайте очереди компенсации вверх и вниз по стеку вызовов.
• это откладывает компенсацию до "окончательного внешнего", что может быть проблемой для вещей, которые необходимо очистить на ранней стадии
• это имеет смысл только тогда, когда вам нужен блок try только для блока finally. Если у вас все равно есть блок catch, вы можете просто добавить здесь finally.

Мне нравится этот подход, но я вижу несколько ограничений.

Во-первых, в оригинале бросок в ранний блок finally не влияет на последующие блоки. В вашей демонстрации бросок неэкспортного действия остановит компенсацию разъединения.

Во-вторых, язык усложнен уродством анонимных классов Java, включая необходимость введения кучи «конечных» переменных, чтобы их могли видеть компенсаторы. Это не твоя вина, но мне интересно, не хуже ли лекарство, чем болезнь.

Но в целом подход мне нравится, и он довольно милый.

На мой взгляд, вам нужны транзакции. Ваши компенсации - это транзакции, реализованные несколько иначе. Я предполагаю, что вы не работаете с ресурсами JPA или любыми другими ресурсами, которые поддерживают транзакции и откаты, потому что тогда было бы довольно просто использовать JTA (API транзакций Java). Кроме того, я предполагаю, что ваши ресурсы разрабатываются не вами, потому что, опять же, вы можете просто заставить их реализовать правильные интерфейсы из JTA и использовать с ними транзакции.

Итак, мне нравится ваш подход, но я бы скрыл от клиента сложность извлечения и компенсации. Кроме того, вы можете прозрачно передавать транзакции.

Таким образом (осторожно, впереди уродливый код):

public class Transaction {
   private Stack<Compensation> compensations = new Stack<Compensation>();

   public Transaction addCompensation(Compensation compensation) {
      this.compensations.add(compensation);
   }

   public void rollback() {
      while(!compensations.empty())
         compensations.pop().compensate();
   }
}

Деструктор, подобный устройству для Java, который будет вызываться в конце лексической области видимости, является интересной темой; его лучше всего решать на языковом уровне, однако языковые цари не находят его очень привлекательным.

Обсуждалось определение действия по разрушению сразу после строительства (ничего нового под солнцем). Примером может служить http://projectlombok.org/features/Cleanup.html.

Другой пример из частного обсуждения:

{
   FileReader reader = new FileReader(source);
   finally: reader.close(); // any statement

   reader.read();
}

Это работает путем преобразования

{
   A
   finally:
      F
   B
}

в

{
   A
   try
   {
      B
   }
   finally
   {
      F
   }
}

Если в Java 8 добавлено закрытие, мы могли бы кратко реализовать эту функцию в закрытии:

auto_scope
#{
    A;
    on_exit #{ F; }
    B;
}

Однако с закрытием большая часть библиотеки ресурсов будет предоставлять свое собственное устройство автоматической очистки, клиентам действительно не нужно обрабатывать его самостоятельно.

File.open(fileName) #{

    read...

}; // auto close

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

// one try finally to rule them all.
try {
   connection = DBusConnection.SessionBus(); // may throw, needs cleanup
   connection.export("/MyObject", myObject ); // may throw, needs cleanup
   // more things which could throw an exception

} finally {
   // unwind more things which could have thrown an exception

   try { connection.unExport( "/MyObject" ); } catch(Exception ignored) { }
   if (connection != null ) connection.disconnect();
}

Используя вспомогательные методы, вы могли бы сделать

unExport(connection, "/MyObject");
disconnect(connection);

Я бы подумал, что отключение означает, что вам не нужно отменять экспорт ресурсов, которые использует соединение.

Вам следует изучить try-with-resources, впервые представленный в Java 7. Это должно уменьшить необходимую вложенность.