О бробка виняткових ситуацій

Лабораторна робота № 5

Тема: «Обробка виключень»

При виконанні програми можуть виникати помилки. В одних випадках це викликано помилками програміста, в інших - зовнішніми причинами. Наприклад, може виникнути помилка вводу/виводу при роботі з файлом або мережним з'єднанням. У класичних мовах програмування, наприклад, було потрібно перевіряти деяку умову, що вказувало на наявність помилки, і залежно від цього вживати ті або інші дії.

Наприклад:

 

...

int statusCode = someAction();

if (statusCode){

... обробка помилки

} else {

statusCode = anotherAction();

if(statusCode) {

... обробка помилки...

}

}

...

В Java з'явилося більш просте й елегантне рішення - обробка виняткових ситуацій.

 

try{

someAction();

anotherAction();

} catch(Exception e) {

// обробка виняткової ситуації

}

Легко помітити, що такий підхід є не тільки витонченим, але й більше надійним і простим для розуміння.

Причини виникнення помилок

Існує три причини виникнення виняткових ситуацій.

· Спроба виконати некоректний вираз. Наприклад, ділення на нуль, або звертання до об'єкта по посиланню, рівної null, спроба використати клас, опис якого (class-файл) відсутній, і т.д. У таких випадках завжди можна точно вказати, у якім місці відбулася помилка, - саме в некоректному вираженні.

· Виконання оператора throw Цей оператор застосовується для явного породження помилки. Очевидно, що й тут можна вказати місце виникнення виняткової ситуації.

· Асинхронні помилки під час виконання програми.

Причиною таких помилок можуть бути збої усередині самої віртуальної машини (адже вона також є програмою), або виклик методу stop() у потоку виконання Thread.

У цьому випадку неможливо вказати точне місце програми, де відбувається виняткова ситуація. Якщо ми спробуємо зупинити потік виконання (викликавши метод stop()), нам не вдасться завбачати, при виконанні якого саме виразу цей потік зупиниться.

Таким чином, всі помилки в Java діляться на синхронні й асинхронні. З першими порівняно простіше працювати, тому що принципово можливо знайти точне місце в коді, що є причиною виникнення виняткової ситуації. Звичайно, Java є строгою мовою в тому розумінні, що всі вираження до крапки збою обов'язково будуть виконані, і в той же час жодне наступне вираження ніколи виконане не буде. Важливо пам'ятати, що помилки можуть виникати як через недостатню уважність програміста (відсутній потрібний клас, або індекс масиву вийшов за припустимі границі), так і по незалежним від нього причинам (відбувся розрив мережного з'єднання, збій апаратного забезпечення, наприклад, жорсткого диска й ін.).

Асинхронні помилки набагато складніше у виявленні й виправленні. Звичайному розробнику дуже важко виявити причини збоїв у віртуальній машині. Це можуть бути помилки творців JVM, несумісність із операційною системою, апаратний збій і багато чого іншого. Все-таки сучасні віртуальні машини реалізовані досить добре й подібні збої відбуваються вкрай рідко (за умови використання якісних комплектуючих).

Аналогічна ситуація спостерігається й у випадку із примусовою зупинкою потоків виконання. Оскільки ця дія виконується операційною системою, ніколи не можна пророчити, у якому саме місці зупиниться потік. Це означає, що програма може багаторазово відпрацювати коректно, а потім зненацька дати збій просто через те, що потік зупинився в якомусь іншому місці. Із цієї причини примусова зупинка не рекомендується.

При виникненні виняткової ситуації керування передається від коду, що викликав виняткову ситуацію, на найближчий блок catch (або нагору по стеку) і створюється об'єкт, успадкований від класу Throwable, або його нащадків (див. діаграму ієрархії класів-виключень), що містить інформацію про виняткову ситуацію й використається при її обробці. Власне, у блоці catch вказується саме клас оброблюваної ситуації. Докладно обробка помилок розглядається нижче.

Ієрархія, по якій передається інформація про виняткову ситуацію, залежить від того, де ця виняткова ситуація виникла. Якщо це

· метод, то керування буде передаватися в те місце, де даний метод був викликаний;

· конструктор, то керування буде передаватися туди, де спробували створити об'єкт (як правило, застосовуючи оператор new);

· статичний ініціалізатор, те керування буде передано туди, де відбулося перше звертання до класу, що його ініціалізувало.

Допускається створення власних класів виняткових ситуацій. Здійснюється це за допомогою механізму спадкування, тобто клас користувальницької виняткової ситуації повинен бути успадкований від класу Throwable, або його нащадків.

Конструкція try-catch

У загальному випадку конструкція виглядає так:

 

try {

...

} catch(SomeExceptionClass e) {

...

} catch(AnotherExceptionClass e) {

...

}

Працює вона в такий спосіб. Спочатку виконується код, який знаходиться у фігурних дужках оператора try. Якщо під час його виконання не відбувається ніяких позаштатних ситуацій, то далі керування передається за закриваючу фігурну дужку останнього оператора catch, асоційованого з даним оператором try.

Якщо в межах try виникає виняткова ситуація, то далі виконання коду виробляється по одному з перерахованих нижче сценаріїв.

Виникла виняткова ситуація, клас якої зазначений як параметр одного із блоків catch. У цьому випадку провадиться виконання блоку коду, асоційованого з даним catch (ув'язненого у фігурні дужки). Далі, якщо код у цьому блоці завершується нормально, те й весь оператор try завершується нормально й керування передається на оператор (вираження), що випливає за закриваючою фігурною дужкою останнього catch. Якщо код в catch завершується не штатно, то й весь try завершується нештатно по тій же причині.

Якщо виникла виняткова ситуація, клас якої не зазначений як аргумент у жодному catch, те виконання всього try завершується нештатно.

Особливі випадки

Під час виконання коду можуть виникати ситуації, які майже не описані в літературі.

Розглянемо таку ситуацію:

 

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.<init>(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.<init>(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.<init>(FileInputStream.java:64)

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

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

Exception hash code 3214658

 

java.io.FileNotFoundException: (The system cannot find the path

specified)

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

at java.io.FileInputStream.<init>(FileInputStream.java:64)

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

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

Exception hash code 6129586

Нескладно помітити, що, хоча послідовність викликів та сама, у викликуваному й зухвалому методах обробляються різні об'єкти виключень.

 

 

Лабораторна робота № 5

Тема: «Обробка виключень»

При виконанні програми можуть виникати помилки. В одних випадках це викликано помилками програміста, в інших - зовнішніми причинами. Наприклад, може виникнути помилка вводу/виводу при роботі з файлом або мережним з'єднанням. У класичних мовах програмування, наприклад, було потрібно перевіряти деяку умову, що вказувало на наявність помилки, і залежно від цього вживати ті або інші дії.

Наприклад:

 

...

int statusCode = someAction();

if (statusCode){

... обробка помилки

} else {

statusCode = anotherAction();

if(statusCode) {

... обробка помилки...

}

}

...

В Java з'явилося більш просте й елегантне рішення - обробка виняткових ситуацій.

 

try{

someAction();

anotherAction();

} catch(Exception e) {

// обробка виняткової ситуації

}

Легко помітити, що такий підхід є не тільки витонченим, але й більше надійним і простим для розуміння.

Причини виникнення помилок

Існує три причини виникнення виняткових ситуацій.

· Спроба виконати некоректний вираз. Наприклад, ділення на нуль, або звертання до об'єкта по посиланню, рівної null, спроба використати клас, опис якого (class-файл) відсутній, і т.д. У таких випадках завжди можна точно вказати, у якім місці відбулася помилка, - саме в некоректному вираженні.

· Виконання оператора throw Цей оператор застосовується для явного породження помилки. Очевидно, що й тут можна вказати місце виникнення виняткової ситуації.

· Асинхронні помилки під час виконання програми.

Причиною таких помилок можуть бути збої усередині самої віртуальної машини (адже вона також є програмою), або виклик методу stop() у потоку виконання Thread.

У цьому випадку неможливо вказати точне місце програми, де відбувається виняткова ситуація. Якщо ми спробуємо зупинити потік виконання (викликавши метод stop()), нам не вдасться завбачати, при виконанні якого саме виразу цей потік зупиниться.

Таким чином, всі помилки в Java діляться на синхронні й асинхронні. З першими порівняно простіше працювати, тому що принципово можливо знайти точне місце в коді, що є причиною виникнення виняткової ситуації. Звичайно, Java є строгою мовою в тому розумінні, що всі вираження до крапки збою обов'язково будуть виконані, і в той же час жодне наступне вираження ніколи виконане не буде. Важливо пам'ятати, що помилки можуть виникати як через недостатню уважність програміста (відсутній потрібний клас, або індекс масиву вийшов за припустимі границі), так і по незалежним від нього причинам (відбувся розрив мережного з'єднання, збій апаратного забезпечення, наприклад, жорсткого диска й ін.).

Асинхронні помилки набагато складніше у виявленні й виправленні. Звичайному розробнику дуже важко виявити причини збоїв у віртуальній машині. Це можуть бути помилки творців JVM, несумісність із операційною системою, апаратний збій і багато чого іншого. Все-таки сучасні віртуальні машини реалізовані досить добре й подібні збої відбуваються вкрай рідко (за умови використання якісних комплектуючих).

Аналогічна ситуація спостерігається й у випадку із примусовою зупинкою потоків виконання. Оскільки ця дія виконується операційною системою, ніколи не можна пророчити, у якому саме місці зупиниться потік. Це означає, що програма може багаторазово відпрацювати коректно, а потім зненацька дати збій просто через те, що потік зупинився в якомусь іншому місці. Із цієї причини примусова зупинка не рекомендується.

При виникненні виняткової ситуації керування передається від коду, що викликав виняткову ситуацію, на найближчий блок catch (або нагору по стеку) і створюється об'єкт, успадкований від класу Throwable, або його нащадків (див. діаграму ієрархії класів-виключень), що містить інформацію про виняткову ситуацію й використається при її обробці. Власне, у блоці catch вказується саме клас оброблюваної ситуації. Докладно обробка помилок розглядається нижче.

Ієрархія, по якій передається інформація про виняткову ситуацію, залежить від того, де ця виняткова ситуація виникла. Якщо це

· метод, то керування буде передаватися в те місце, де даний метод був викликаний;

· конструктор, то керування буде передаватися туди, де спробували створити об'єкт (як правило, застосовуючи оператор new);

· статичний ініціалізатор, те керування буде передано туди, де відбулося перше звертання до класу, що його ініціалізувало.

Допускається створення власних класів виняткових ситуацій. Здійснюється це за допомогою механізму спадкування, тобто клас користувальницької виняткової ситуації повинен бути успадкований від класу Throwable, або його нащадків.

О бробка виняткових ситуацій

Конструкція try-catch

У загальному випадку конструкція виглядає так:

 

try {

...

} catch(SomeExceptionClass e) {

...

} catch(AnotherExceptionClass e) {

...

}

Працює вона в такий спосіб. Спочатку виконується код, який знаходиться у фігурних дужках оператора try. Якщо під час його виконання не відбувається ніяких позаштатних ситуацій, то далі керування передається за закриваючу фігурну дужку останнього оператора catch, асоційованого з даним оператором try.

Якщо в межах try виникає виняткова ситуація, то далі виконання коду виробляється по одному з перерахованих нижче сценаріїв.

Виникла виняткова ситуація, клас якої зазначений як параметр одного із блоків catch. У цьому випадку провадиться виконання блоку коду, асоційованого з даним catch (ув'язненого у фігурні дужки). Далі, якщо код у цьому блоці завершується нормально, те й весь оператор try завершується нормально й керування передається на оператор (вираження), що випливає за закриваючою фігурною дужкою останнього catch. Якщо код в catch завершується не штатно, то й весь try завершується нештатно по тій же причині.

Якщо виникла виняткова ситуація, клас якої не зазначений як аргумент у жодному catch, те виконання всього try завершується нештатно.