Переопределенные методы не могут генерировать исключения Java

Это мой кодовый блок.

class Alpha{
    public void Gamma() {
        System.out.println("Alphas");
    }
}

class Beta extends Alpha{
    public void Gamma() throws Exception //Line 1
    {
        try {
            System.out.println("Betas");
        } catch(Exception e) {
            System.out.println("Exception caught");
        } finally {
            System.out.println("xfg");
        }
    }
    public static void main(String[] args) throws Exception {
        Alpha g = new Beta();
        g.Gamma();
    }
}

Этот код не скомпилируется, потому что я добавил "броски" в Line1.

Компилятор жалуется, что переопределенные методы не могут генерировать исключения.

Почему так?.

Зачем использовать переопределенный метод для исключения?

Потому что я могу переопределить метод из базового класса, добавив n строк кода в реализацию дочернего класса.

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

ОТВЕТЫ

Ответ 1

Переопределенные методы могут вызывать исключения, пока переопределенный метод также выдает те же Исключения. Вы не можете вводить новые Исключения.

Итак, почему вы не можете ввести новое исключение?

Одна из центральных концепций ООП использует абстрактные типы и что все подтипы можно рассматривать как абстрактный тип. См. Принцип замены Лискова

Причина, по которой вы не можете ввести более широкое поведение, заключается в том, что если метод абстрактного типа (суперкласс или интерфейс) не генерирует исключение и вы ссылаетесь на свой объект как на этот тип, вы получите неожиданное поведение:

Alpha alpha = new Beta();
// At this point, the compiler knows only that we have an Alpha
alpha.myMethod();

Если Alpha myMethod() не выбрасывает исключение, но делает Beta, мы могли бы получить неожиданное исключение в приведенном выше коде.

Ответ 2

Переопределенный метод/методы подкласса может генерировать (объявлять) только непроверенное исключение, как ArrayIndexOutOfBoundsException.

Но вы не можете бросить (объявить) проверенное исключение. как IOException.

пример переопределения методов, генерирующих исключения Java

class A{
 public void show(){
   // some code here
  }
}

class B extends A{
public void show() throws ArrayIndexOutOfBoundsException{
   // some code here
  }
}

Надеюсь, это поможет вам.

Ответ 3

Ваша клиентская сторона всегда думает иметь дело с базовой версией. То, что вся польза полиморфизма = > клиентская сторона игнорирует переопределенный.

Таким образом, ничто не заставит клиента разобраться с определенными правилами, сделанными overriden, здесь случай потенциального исключения, вызванного переопределенным методом.

Вот почему метод overriden не может генерировать более широкие исключения. Это нарушит контракт.

Таким образом, в отношении этой логики правило: Override метод CAN (если он хочет) только выдает подчасти из исключений, объявленных в базовой версии, НО НЕ МОЖЕТ отбрасывать более широкие.

Ответ 4

В правиле говорится

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

Ответ 5

Компилятор жалуется, что переопределенные методы не могут генерировать исключения

Нет, нет. Прочтите сообщение еще раз. В нем говорится, что вы не можете генерировать исключение, которое не объявляется вызываемым переопределенным методом. Не то же самое.

Ответ 6

ваш выше код в основном методе

Alpha g = new Beta(); // теперь он создает новый фактический объект класса Бета с refrence Alpha

g.Gamma(); // * теперь компилятор выглядит только для метода Gamma(), который представлен в классе Alpha вне курса, который присутствует в классе Beta также по умолчанию через inheritance.but, компилятор посмотрел только на класс Alpha и задал вопрос, содержит метод Gamma() и нашел ответ да, это было.

Предположим, что условие, когда java-компилятор дает возможность вызывать более проверенные исключения в методе gamma() в Бета-классе, то что произойдет

  • теперь во время компиляции компилятора зависит только от метода Gamma() класса Alpha.it, который не принуждает обрабатывать это исключение или выбрасывает это исключение, которое является неправильным, потому что оно может быть брошено (предположим, что java-компилятор разрешает бросать больше проверок исключение в переопределенном методе). но на самом деле компилятор не делает ограничений на бросание исключений, но также и на модификатор доступности.

    поскольку вызов нестатического метода происходит по методу фактического объекта, а не по типу, и мы указываем на какой-либо супер-тип, а во время компиляции компилятор проверяет доступность и наличие в этом типе назначенного класса.

поэтому я думаю, что причина этого переопределенного контракта

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