Кто определяет непроверяемость исключения

Кто определяет непроверяемость исключения в Java

Непроверяемость (unchecked status) исключения определяется наследованием от класса RuntimeException, а не действиями разработчика. Это решение заложено в архитектуре Java.

Иерархия исключений в Java

java.lang.Throwable
    ├── java.lang.Exception
    │   ├── java.lang.RuntimeException  // ✓ Непроверяемые (Unchecked)
    │   │   ├── NullPointerException
    │   │   ├── IllegalArgumentException
    │   │   ├── IndexOutOfBoundsException
    │   │   ├── ArithmeticException
    │   │   └── ... другие
    │   │
    │   └── Проверяемые исключения (Checked)  // Всё остальное
    │       ├── IOException
    │       ├── SQLException
    │       ├── FileNotFoundException
    │       └── ... другие
    │
    └── java.lang.Error  // ✓ Непроверяемые
        ├── OutOfMemoryError
        ├── StackOverflowError
        └── ... другие

Ключевой принцип

Если исключение наследует RuntimeException → непроверяемое (unchecked) Если исключение наследует Exception (но не RuntimeException) → проверяемое (checked)

Это определение заложено в компиляторе Java и не зависит от разработчика.

Примеры

Проверяемые исключения (Checked)

// ❌ Ошибка компиляции — не обработана IOException
public void readFile(String path) {
    FileReader reader = new FileReader(path);  // Компилятор: "Обработай IOException!"
    // ...
}

// ✓ Правильно — явно указываем throws
public void readFile(String path) throws IOException {
    FileReader reader = new FileReader(path);
    reader.close();
}

// ✓ Или перехватываем
public void readFile(String path) {
    try {
        FileReader reader = new FileReader(path);
        reader.close();
    } catch (IOException e) {
        System.err.println("Ошибка чтения файла: " + e.getMessage());
    }
}

// IOException наследует Exception (но не RuntimeException)
public class IOException extends Exception { }

Непроверяемые исключения (Unchecked)

// ✓ Компилятор НЕ требует обработки
public void divide(int a, int b) {
    int result = a / b;  // Может выкинуть ArithmeticException
    System.out.println(result);
}

// Можем обработать, но не обязаны
public void divideWithHandling(int a, int b) {
    try {
        int result = a / b;
    } catch (ArithmeticException e) {
        System.err.println("Деление на ноль!");
    }
}

// NullPointerException — непроверяемое
public void processString(String str) {
    // Компилятор НЕ заставляет обработать NPE
    int length = str.length();  // Если str == null → NPE, но не ошибка компиляции
}

// ArithmeticException наследует RuntimeException
public class ArithmeticException extends RuntimeException { }

// NullPointerException наследует RuntimeException
public class NullPointerException extends RuntimeException { }

Кто ИМЕННО определяет непроверяемость?

1. Язык Java (JVM спецификация)

Механизм разделения исключений определён в Java Language Specification (JLS):

// ✓ Если наследуешь RuntimeException → непроверяемое
public class MyRuntimeException extends RuntimeException {
    public MyRuntimeException(String message) {
        super(message);
    }
}

// ❌ Если наследуешь Exception (не RuntimeException) → проверяемое
public class MyCheckedException extends Exception {
    public MyCheckedException(String message) {
        super(message);
    }
}

// Использование
public void testUnchecked() {
    throw new MyRuntimeException("Это непроверяемое");  // ✓ OK, не нужен throws
}

public void testChecked() throws MyCheckedException {
    throw new MyCheckedException("Это проверяемое");  // ❌ Обязателен throws
}

2. Компилятор javac

Компилятор проверяет наследование и требует явного указания throws для проверяемых исключений.

3. Java Runtime (JVM)

При выполнении JVM не различает проверяемые и непроверяемые — просто выкидывает исключение. Различие действует только на уровне компиляции.

Практический пример

public class ExceptionHierarchyExample {
    
    // Проверяемое исключение
    static class DatabaseException extends Exception {
        public DatabaseException(String message) {
            super(message);
        }
    }
    
    // Непроверяемое исключение
    static class InvalidConfigException extends RuntimeException {
        public InvalidConfigException(String message) {
            super(message);
        }
    }
    
    // ❌ Ошибка компиляции — не обработан DatabaseException
    public void queryDatabase() throws DatabaseException {
        if (!isConnected()) {
            throw new DatabaseException("No connection");
        }
    }
    
    // ✓ OK — RuntimeException не требует обработки
    public void loadConfig() {
        if (config == null) {
            throw new InvalidConfigException("Config is missing");
        }
    }
    
    // Использование
    public void process() {
        try {
            queryDatabase();  // ❌ Обязателен try-catch или throws
        } catch (DatabaseException e) {
            System.err.println("Database error: " + e);
        }
        
        loadConfig();  // ✓ OK, можем не ловить
    }
}

Почему Java так устроена?

Checked exceptions

Плюсы:

• Заставляет думать об ошибках
• API явно показывает, какие исключения может выкинуть
• Лучше контролируемость

// API явно показывает исключения
public InputStream openFile(String path) throws FileNotFoundException, IOException {
    // Я должен обработать эти исключения
}

Минусы:

• Boilerplate код (try-catch везде)
• Нарушает инкапсуляцию (низкоуровневая ошибка лезет выше)

Unchecked exceptions

Плюсы:

• Для ошибок программиста (NPE, IndexOutOfBoundsException)
• Не заставляет обрабатывать неожиданные ошибки
• Меньше boilerplate

Минусы:

• Можно забыть обработать
• Непредсказуемость

Типичная ошибка разработчиков

// ❌ Неправильно — пытаемся заставить обработку RuntimeException
// (компилятор не требует, но мы думаем, что требует)
public void wrongApproach() throws NullPointerException {
    // NullPointerException extends RuntimeException
    // throws не имеет смысла — это непроверяемое исключение
    String str = null;
    System.out.println(str.length());  // throws в сигнатуре не поможет
}

// ✓ Правильно — явно обрабатываем NPE
public void correctApproach() {
    try {
        String str = null;
        System.out.println(str.length());
    } catch (NullPointerException e) {
        System.err.println("Null pointer!");
    }
}

Кастомные исключения

// Если нам нужно непроверяемое исключение
public class InvalidPaymentException extends RuntimeException {
    private final PaymentStatus status;
    
    public InvalidPaymentException(String message, PaymentStatus status) {
        super(message);
        this.status = status;
    }
    
    public PaymentStatus getStatus() {
        return status;
    }
}

// Использование — компилятор НЕ требует обработки
public void processPayment(Payment payment) {
    if (payment.getAmount() < 0) {
        throw new InvalidPaymentException("Negative amount", PaymentStatus.INVALID);
    }
}

// Если нам нужно проверяемое исключение
public class PaymentProcessingException extends Exception {
    public PaymentProcessingException(String message, Throwable cause) {
        super(message, cause);
    }
}

// Использование — компилятор ТРЕБУЕТ обработки
public void processPaymentWithChecked(Payment payment) throws PaymentProcessingException {
    if (!isValidPayment(payment)) {
        throw new PaymentProcessingException("Invalid payment", null);
    }
}

Вывод

Непроверяемость исключения определяется НАСЛЕДОВАНИЕМ:

1. extends RuntimeException → Непроверяемое (unchecked)

   • Компилятор не требует обработки
   • Для ошибок программиста
   • Пример: NullPointerException, IllegalArgumentException

2. extends Exception (но не RuntimeException) → Проверяемое (checked)

   • Компилятор требует throws или try-catch
   • Для ожидаемых ошибок
   • Пример: IOException, SQLException

3. extends Error → Непроверяемое (системные ошибки JVM)

   • Обычно не ловим
   • Пример: OutOfMemoryError, StackOverflowError

Это решение встроено в язык Java и компилятор, не зависит от разработчика при использовании исключений, только при их определении.