Программирование Java

При нормальном завершении тела try-with-resources какое исключение станет основным, если закрытие ресурса завершится ошибкой?

В аварийном шлюзе приложения предлагают заменить catch(Exception) на catch(Throwable): какое принципиальное последствие это создаёт для обработки ошибок?

Ситуация: приложение больше не использует объект открытого файла; почему сборка мусора не гарантирует своевременное освобождение самого файла?

Внутри метода ресурс объявлен в заголовке try-with-resources. Доступен ли этот ресурс в блоках catch и finally?

Что теряет поток, если обработчик InterruptedException поглощает его, не восстановив флаг прерывания?

В каком порядке выполняются блоки finally при раскрутке стека после исключения из глубоко вложенного вызова?

Что произойдёт с клиентским кодом при добавлении проверяемого исключения в объявление throws уже опубликованного метода?

Куда передаётся неперехваченное исключение после завершения поиска обработчика в стеке вызовов потока?

Почему этот фрагмент компилируется, хотя first используется при инициализации следующего ресурса?

class Demo {
    static class R implements AutoCloseable {
        R child() { return new R(); }
        public void close() { }
    }

    static void run() {
        try (R first = new R();
             R second = first.child()) {
            // работа с обоими ресурсами
        }
    }
}

В методе ниже обработчик поглощает исключение из try. Нужно ли всё равно объявлять throws IOException для компиляции?

class Demo {
    static void run() {
        try {
            throw new IllegalStateException();
        } catch (RuntimeException e) {
            System.out.println("handled");
        } finally {
            throw new java.io.IOException();
        }
    }
}

Что гарантирует интерфейс AutoCloseable относительно повторного вызова close()?

Что изменится в диагностике try-with-resources, если у основного исключения отключён механизм подавления?

В try-with-resources один и тот же объект AutoCloseable указан в двух ресурсных позициях. Сколько раз Java вызовет его close()?

Кто обязан закрыть ресурс, возвращённый фабричным методом, если ресурс не передан в try-with-resources?

Класс исключения напрямую наследует Throwable, не являясь подклассом RuntimeException или Error. Как компилятор классифицирует такое исключение?

Проверьте, будет ли вызван close(), если конструктор ресурса завершился исключением:

class Demo {
    static class R implements AutoCloseable {
        R() {
            System.out.println("construct");
            throw new RuntimeException("init");
        }

        @Override
        public void close() {
            System.out.println("close");
        }
    }

    public static void main(String[] args) {
        try (R r = new R()) {
        } catch (RuntimeException e) {
            System.out.println("caught");
        }
    }
}

Допустима ли для вызывающего кода ссылка на объект, если его конструктор завершился исключением?

Какие ограничения действуют при установке причины исключения через initCause после его создания?

Если закрытие одного из нескольких ресурсов в try-with-resources выбросило исключение, будут ли закрыты остальные ресурсы?

Сравните роль throw и throws при работе Java-метода с исключениями.