Н.А. Вязовик - Программирование на Java

public class BaseClass {

public void method () throws IOException {

...

}

}

public class LegalOne extends BaseClass {

public void method () throws IOException {

...

}

}

public class LegalTwo extends BaseClass {

public void method () {

...

}

}

public class LegalThree extends BaseClass {

public void method ()

throws

EOFException,MalformedURLException {

...

}

}

public class IllegalOne extends BaseClass {

public void method ()

throws

IOException,IllegalAccessException {

...

}

}

public class IllegalTwo extends BaseClass {

public void method () {

...

throw

new Exception();

}

}

В данном случае:

* определение класса LegalOne будет корректным, так как переопределение метода method() верное (список ошибок не изменился);

* определение класса LegalTwo будет корректным, так как переопределение метода method() верное (новый метод не может выбрасывать ошибок, а значит, не расширяет список возможных ошибок старого метода);

* определение класса LegalThree будет корректным, так как переопределение метода method() будет верным (новый метод может создавать исключения, которые являются подклассами исключения, возбуждаемого в старом методе, то есть список сузился);

* определение класса IllegalOne будет некорректным, так как переопределение метода method() неверно ( IllegalAccessException не является подклассом IOException, список расширился);

* определение класса IlegalTwo будет некорректным: хотя заголовок method() объявлен верно (список не расширился), в теле метода бросается исключение, не указанное в throws.

Особые случаи

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

Рассмотрим такую ситуацию:

import java.io.*;

public class Test {

public Test() {

}

public static void main(String[] args) {

Test test = new Test();

try {

test.doFileInput("bogus.file");

}

catch (IOException ex) {

System.out.println("Second exception handle stack trace");

ex.printStackTrace();

}

}

private String doFileInput(String fileName)

throws FileNotFoundException,IOException {

String retStr = "";

java.io.FileInputStream fis = null;

try {

fis = new java.io.FileInputStream(fileName);

}

catch (FileNotFoundException ex) {

System.out.println("First exception handle stack trace");

ex.printStackTrace();

throw ex;

}

return retStr;

}

}

Результат работы будет выглядеть следующим образом:

java.io.FileNotFoundException: bogus.file (The system cannot find the file specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:64) at experiment.Test.doFileInput(Test.java:33) at experiment.Test.main(Test.java:21) First exception handle stack trace java.io.FileNotFoundException: bogus.file (The system cannot find the file specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:64) at experiment.Test.doFileInput(Test.java:33) at experiment.Test.main(Test.java:21) Second exception handle stack trace

Так как при вторичном возбуждении используется один и тот же объект Exception, стек в обоих случаях будет содержать одну и ту же последовательность вызовов. То есть при повторном возбуждении исключения, если мы используем тот же объект, изменения его параметров не происходит.

Рассмотрим другой пример:

import java.io.*;

public class Test {

public Test() {

}

public static void main(String[] args) {

Test test = new Test();

try {

test.doFileInput();

}

catch (IOException ex) {

System.out.println("Exception hash code " + ex.hashCode());

ex.printStackTrace();

}

}

private String doFileInput()

throws FileNotFoundException,IOException {

String retStr = "";

java.io.FileInputStream fis = null; try {

fis = new java.io.FileInputStream("bogus.file");

}

catch (FileNotFoundException ex) {

System.out.println("Exception hash code " + ex.hashCode());

ex.printStackTrace();

fis = new java.io.FileInputStream("anotherBogus.file");

throw ex;

}

return retStr;

}

}

java.io.FileNotFoundException: bogus.file (The system cannot find

the file specified)

at java.io.FileInputStream.open(Native Method)

at java.io.FileInputStream.(FileInputStream.java:64)

at experiment.Test.doFileInput(Test.java:33)

at experiment.Test.main(Test.java:21)

Exception hash code 3214658

java.io.FileNotFoundException: anotherBogus.file (The system cannot find

the path specified)

at java.io.FileInputStream.open(Native Method)

at java.io.FileInputStream.(FileInputStream.java:64)

at experiment.Test.doFileInput(Test.java:38)

at experiment.Test.main(Test.java:21)

Exception hash code 6129586

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

Заключение

В данной лекции рассмотрены основные языковые конструкции.

Для организации циклов в Java предназначены три основных конструкции: while, do, for. Для изменения порядка выполнения операторов применяются continue и break (с меткой или без). Также существуют два оператора ветвления: if и switch.

Важной темой является обработка ошибок, поскольку без нее не обходится ни одна программа, ведь причиной сбоев может служить не только ошибка программиста, но и внешние события, например, разрыв сетевого соединения. Основной конструкцией обработки исключительных ситуаций является try-catch-finally. Для явной инициализации исключительной ситуации служит ключевое слово throw.

Ошибки делятся на проверяемые и непроверяемые. Чтобы повысить надежность программы, компилятор требует обработки исключений, классы которых наследуются от Exception, кроме классов-наследников RuntimeException. Предполагается, что такие ошибки могут возникать не столько по ошибке разработчика, сколько по внешним неконтролируемым причинам.

Классы, унаследованные от RuntimeException, описывают программные сбои. Ожидается, что программист сведет вероятность таких ошибок к минимуму, а потому, чтобы не загромождать код, они являются непроверяемыми, компилятор оставляет обработку на усмотрение разработчика. Ошибки-наследники Error свидетельствуют о фатальных сбоях, поэтому их также необязательно обрабатывать.

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

Переопределенный ( overridden ) метод не может расширять список возможных исключений исходного метода.

Эта лекция начинает рассмотрение базовых библиотек Java, которые являются неотъемлемой частью языка и входят в его спецификацию, а именно описывается пакет java.awt, предоставляющий технологию AWT для создания графического (оконного) интерфейса пользователя – GUI. Ни одна современная программа, предназначенная для пользователя, не обходится без удобного, понятного, в идеале – красивого пользовательского интерфейса. С самой первой версии в Java существует специальная технология для создания GUI. Она называется AWT, Abstract Window Toolkit. Именно о ней пойдет речь в этой лекции. Пакет java.awt претерпел, пожалуй, больше всего изменений с развитием версий Java. Мы рассмотрим дерево компонентов, доступных программисту, специальную модель сообщений, позволяющую гибко обрабатывать пользовательские действия, и другие особенности AWT – работа с цветами, шрифтами, отрисовка графических примитивов, менеджеры компоновки и т.д. Хотя технология AWT включает в себя гораздо больше, чем можно изложить в рамках одной лекции

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

Введение

Поскольку Java-приложения предназначены для работы на разнообразных платформах, реализация графического пользовательского интерфейса (GUI) должна быть либо одинаковой для любой платформы, либо, напротив, программа должна иметь вид, типичный для данной операционной системы. В силу ряда причин, для основной библиотеки по созданию GUI был выбран второй подход. Во-первых, это лишний раз показывало гибкость Java – действительно, пользователи разных платформ могли работать с одним и тем же Java-приложением, не меняя своих привычек. Во-вторых, такая реализация обеспечивала большую производительность, поскольку была основана на возможностях операционной системы. В частности, это означало и более компактный, простой, а значит, и более надежный код.