2013-09-18 1 views
1

Я пытаюсь понять разницу, почему дочерний класс не может переопределить реализацию методы родительского класса, чтобы поймать исключение, но никаких проблем при ловле ошибки,Throw Error, Exception и выполнение исключений в дочернем классе

Например, в приведенном ниже сценарии, когда я удаляю «Исключение» из предложения throws, он компилируется отлично.

class Supertest { 

    public void amethod(int i, String s) { 

    } 

} 

public class test extends Supertest { 

    public void amethod(int i, String s) throws Error, Exception { 

    } 

} 
+0

Возможный дубликат: http://stackoverflow.com/questions/5875414/method-overriding-and-exceptions – dcp

ответ

8

Error - это беспрепятственное исключение. Exception - checked exception. Это так просто. Так оно и должно быть разумно иметь такой код:

Supertest x = new test(); 
x.amethod(10, "foo"); 

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

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

От section 8.4.8.3 из JLS:

Более точно, предположим, что В представляет собой класс или интерфейс, и А представляет собой суперкласс или суперинтерфейс B, и объявление метода п в B переопределяет или скрывает метод декларация m в A. Затем:

  • Если n имеет предложение throw, в котором упоминаются все проверенные типы исключений, то m должно иметь предложение throws или возникает ошибка времени компиляции.
  • Для каждого проверяемого типа исключения, указанного в предложении throws of n, тот же класс исключений или один из его супертипов должен произойти в стирании (§4.6) предложения throws m; в противном случае возникает ошибка времени компиляции.
+1

@OP выделяет предложение отдельно, в общем случае вы не можете наложить больше ограничений на переопределенный метод. Это включает в себя изменение типа возврата из '' Integer'' '' ''. –

+0

Действительно - или изменить параметр метода из 'Number' в' Integer'. –

+0

Я предполагаю, что изменение типа параметра будет компилируемо и рассматривается как перегрузка метода. –

0

Скажем, у вас есть

SuperTest superTest = new test(); 
superTest.amethod(); 

во время компиляции, методы разрешаются с объявленной или статическим типом переменной. SuperTest#amethod объявляется без выброса исключенного исключения Exception, поэтому его дети должны следовать этим правилам.

Error - это беспрепятственное исключение. Его не нужно поймать. Таким образом, объявление родительского метода не ограничивает его.

0

Если метод суперкласса не объявляет об исключении, то метод переопределения подкласса не может объявить какое-либо проверенное исключение.

Здесь Exception проверяется и Error является unchecked.So вы не можете бросить Exception.
Ссылка http://www.javatpoint.com/exception-handling-with-method-overriding

2

Предложения броска должны быть ковариантными.

Это похоже на требование типов возвращаемых преобладающих методов:

SuperClass 
    Pet method() 

SubClass 
    Cat method() 

здесь Cat является подтипом Pet, поэтому главнейшей является законным.

Тот же принцип применяется к статье throws, которая также является частью выходного сигнала метода.

SuperClass 
    Pet method() throws PetException 

SubClass 
    Cat method() throws CatException 

это законно, если CatException является подтипом PetException.

Если предложение throw метода пусто, оно неявно RuntimeException|Error. Все переопределяющие методы должны только бросать подтипы этого. Excepiton|RuntimeException|Error не является подтипом RuntimeException|Error.