В Java существует старое, но всё ещё актуальное ограничение: если метод бросает checked‑исключение (например, IOException), он обязан явно объявить это с помощью throws. Это требование — не от JVM, а от компилятора. Компилятор жёстко следит за декларациями, но вот JVM — нет. Что создаёт любопытную лазейку: обойти компилятор, оставаясь при этом в рамках спецификации JVM.
Сегодня разберёмся, как это сделать с помощью Unsafe.throwException(), почему это вообще работает, где это может пригодиться, и на что стоит обратить внимание при использовании Java 17, 21 и 24.
Unsafe — это внутренний API. Он неофициальный, может быть удалён или ограничен в будущих версиях JDK. Используйте с пониманием и осторожностью.
Проблема: checked-исключения в методах без throws
В Java есть множество интерфейсов, сигнатуры которых не содержат throws: Runnable, Callable, Supplier, Consumer, Function и многие другие. Это отлично подходит для лямбд, но вызывает проблемы, если вдруг в реализации нужно бросить IOException, SQLException или любое другое checked‑исключение.
Пример:
Runnable r = () -> {
throw new IOException("Не могу в сеть"); // Ошибка компиляции
};Компилятор говорит: нельзя. JVM бы с радостью исполнила — но компилятор не даст собрать.
Решение: Unsafe.throwException(Throwable)
Старый добрый sun.misc.Unsafe, один из самых мощных (и потенциально опасных) классов в Java. Внутри него есть метод:
public native void throwException(Throwable t);Этот метод кидает исключение в обход компилятора. Потому что JVM разрешает это. Компилятор — нет. А Unsafe работает на уровне JVM.
Пример:
import sun.misc.Unsafe;
import java.lang.reflect.Field;
import java.io.IOException;
public class UnsafeThrower {
private static final Unsafe unsafe = getUnsafe();
public static void sneakyThrow(Throwable t) {
unsafe.throwException(t);
}
private static Unsafe getUnsafe() {
try {
Field f = Unsafe.class.getDeclaredField("theUnsafe");
f.setAccessible(true);
return (Unsafe) f.get(null);
} catch (Exception e) {
throw new RuntimeException("Не удалось получить Unsafe", e);
}
}
public static void main(String[] args) {
sneakyThrow(new IOException("Проверка"));
System.out.println("Этот код не выполнится");
}
}Скомпилируется и выполнится. Исключение вылетит. throws нигде не написан — но всё работает.
Почему это работает? Потому что компилятор Java строго различает checked и unchecked исключения. Но JVM об этом не знает вовсе. В байткоде нет различий между RuntimeException и IOException. Исключения обрабатываются через инструкцию athrow, и JVM просто передаёт объект Throwable дальше по стеку вызовов.
Метод Unsafe.throwException() вызывает athrow напрямую, обходя все компиляторские барьеры. Это даёт контроль над тем, что вылетает из метода.
Байткод глазами JVM
javap -c -p UnsafeThrowerВы увидите инструкции вроде:
0: new #2 // class java/io/IOException
3: dup
4: ldc #3 // String Проверка
6: invokespecial #4 // Method java/io/IOException.<init>
9: invokestatic #5 // Method sneakyThrow:(Ljava/lang/Throwable;)V
12: returnВсё, что нужно — прямой вызов метода, бросающего исключение. JVM не спрашивает про throws.
Примеры применения
Тестирование поведения ошибок
Мокаете интерфейс, который не может бросать IOException, но вы хотите протестировать такой сценарий:
when(service.fetch()).thenAnswer(inv -> {
UnsafeThrower.sneakyThrow(new IOException("Сервис упал"));
return null;
});Теперь можно проверять, как клиентская логика справляется с сетевыми ошибками.
DI-контейнеры, Proxy, Reflection
try {
Method m = clazz.getMethod("run");
m.invoke(obj);
} catch (InvocationTargetException e) {
UnsafeThrower.sneakyThrow(e.getCause());
}Вызывается метод, который может выбросить что угодно. Без throws. Но не теряем оригинальное исключение — пробрасываем как есть.
Лямбды и функциональные интерфейсы
@FunctionalInterface
interface ThrowingRunnable {
void run() throws Exception;
}
static Runnable wrap(ThrowingRunnable r) {
return () -> {
try {
r.run();
} catch (Exception e) {
UnsafeThrower.sneakyThrow(e);
}
};
}Идеально ложится в Executors.newSingleThreadExecutor().submit(...).
Современные альтернативы
Generic cast hack — type erasure
@SuppressWarnings("unchecked")
public static <T extends Throwable> void sneakyThrow(Throwable t) throws T {
throw (T) t;
}Метод обманывает компилятор с помощью generic type erasure. Ты обещаешь, что бросаешь исключение типа T, но на самом деле кидаешь всё, что угодно. JVM не проверяет тип T, потому что он стерт в рантайме. Компилятор не ругается, потому что думает, что ты кидаешь Throwable, а не, скажем, IOException.
Это способ чуть менее рискованный, чем Unsafe, но требует suppress warnings и понимания generics.
Пример применения:
public static <T> Supplier<T> sneakySupplier(ThrowingSupplier<T> supplier) {
return () -> {
try {
return supplier.get();
} catch (Exception e) {
return sneakyThrow(e);
}
};
}Lombok @SneakyThrows — compile-time
@SneakyThrows
void method() {
throw new IOException("Ломбок! Ломбок повсюду");
}Этот подход работает иначе. Lombok модифицирует AST во время компиляции и добавляет throws Throwable в байткод, даже если ты его не пишешь в коде. В результате метод реально объявляет throws, просто ты этого не видишь.
Но есть минусы. Все это работает только при compile‑time и не годится для runtime‑прокидки (через reflection, DI и т. п.)
Если ты на Java 17, 21, 24:
@SuppressWarnings("unchecked")
public static <T extends Throwable> void sneakyThrow(Throwable t) throws T {
throw (T) t;
}Для jdk.internal.misc.Unsafe:
--add-exports java.base/jdk.internal.misc=ALL-UNNAMEDБез этого не получится даже через рефлексию достать Unsafe.
А вы сталкивались с задачами, где приходилось обходить throws? Делитесь в комментариях.
Если вам интересны нестандартные технические приёмы, архитектурные решения и тонкости работы с Java-платформой — присоединяйтесь к открытым урокам в Otus, где мы разбираем практические кейсы и реальные задачи: