Аналіз виключень

Наступним кроком має бути перехоплення і подальший аналіз виключення. Для цього команда Catch приводиться до наступного вигляду:

Catch excep As Exception

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

Catch ехсер As Exception

Console.WriteLine(excep)

Результат виглядає приблизно так:

System.IndexOutOfRangeException:

An exception of type_ System.IndexOutOfRangeException

was thrown, at Exception_l.Exception!.Main() in

C:\documents and_ Settings\x20\my Documentswisual Studio

Projects\consoleapplication!4\Exception.vb:1ine 6

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

При знайомстві з цим прикладом виникає логічне питання. Допустимо, користувач ввів ім'я файлу, але метод Processfile не може його обробити. Що тоді? Чи можна відрізнити одне виключення від іншого? Як ви незабаром побачите, невелике ускладнення секції Catch дозволяє розрізняти виключення по категоріях. Більш того, в секції Catch можна навіть наново ініціювати перехоплене виключення командою Throw, щоб продовжити його обробку.

Наявність декількох секцій Catch

Одній секції Try в VB .NET може відповідати декілька секцій Catch. Кожна секція перехоплює певну категорію виключень, при цьому для ідентифікації помилок використовуються об'єкти класів, похідних від базового класу Exception. Приклад:

Sub Main()

Dim args(). argument As String Try

args = Environment.GetCormandLineArgs()

Processfile(argsd))

Catch indexproblem As Indexoutofrangeexception

Console.WriteLine("ERROR - No file name supplied")

Catch ioproblem As System.10.i0exception

Console.WriteLine("ERROR - can't process file named " & args(D)

Catch except As Exception

' Інші виключення

End Try

Console.WriteLine("Press enter to end")

Console. Readline()

End Sub

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

Виявивши відповідну секцію Catch, VB виконує її. Код інших секцій Catch при цьому не виконується.

Збіг вважається за виявлений, якщо поточне виключення відноситься до типу, вказаного в заголовку секції Catch, або похідному від нього. Наприклад, клас Filenotfoundexception є похідним від I0exception, тому наступний фрагмент неправильний:

Try

Processfile(args(1))

Catch indexproblem As Indexoutofrangeexception

Console.WriteLinet"ERROR = No file name supplied")

Catch Ioproblem As System.IO.l0Exception

Console. Writelinet "ERROR = can't process file named " & args(D)

Catch filenotfound As System.IO.FileNotFoundException

End Try

Спеціалізоване виключення Filenotfoundexception буде поглинено попередньою секцією, що перехоплює виключення базового класу l0exception.

Із сказаного виходить, що розміщувати секції Catch після секції Catch e As Exception марно. Вказівка типу Exception в першій секції Catch автоматично перекриває решту всіх секцій (до речі кажучи, секція Catch без явної вказівки типу виключення вважається еквівалентною Catch e As Exception). Також слід враховувати, що порожня секція з умовою Catch e As Exception нагадує дуже небезпечну конструкцію On Error Resume з колишніх версій VB.

Не дивлячись на всі небезпеки, пов'язані з перехопленням узагальнених виключень Catch e As Exception, цю перевірку рекомендується включати в останню секцію Catch будь-якого блоку Try — особливо на стадії розробки і тестування, оскільки ця перевірка допомагає краще ізолювати помилки. Якщо решта всіх способів не допомагає, спробуйте вивести вміст стека на консоль або у файл методом Stacktrace класу узагальненого виключення Exception. Приклад:

Try
Processfile(argsd))

Catch indexproblem As Indexoutofrangeexception
Console.WriteLine("ERROR - No file name supplied")

Catch fnf As System.I0.FileNotFoundException
Console.WriteLinet"ERROR - FILE NOT FOUND")

Catch ioproblem As System.I0.lOException
Console.WriteLine("ERROR - can't process file named " & args(1))

Catch e As Exception
Console.WriteLinet"Please inform the writer of this program " & _

"of this message")
Console.Writete.StackTrace)

End Try
Що відбудеться, якщо виникле виключення не підійде ні до однієї з секцій Catch, а в кінці блоку Try-catch відсутня універсальна секція Catch e As Exception? В цьому випадку виключення передається в секцію Try верхнього рівня, що укладає код внутрішньої секції Try. Якщо відповідна секція Catch не буде знайдена і в зовнішній секції Try, пошук продовжується в методі, від якого поступив виклик. Ймовірно, саме це і відбудеться при виклику методу Processfi I e з попереднього прикладу — метод Processfi 1е передає всі необроблені виключення (у формі об'єкту Exception) в процедуру Sub Main.

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

У загальному випадку, якщо виключення не було оброблене програмою аж до точки входу в додаток .NET виводить повідомлення з описом виключення і вміст стека з інформацією про всі викликані методи на момент виникнення виключення.
У VB .NET секція Catch може доповнюватися умовою When, що розширює можливості її застосування. Синтаксис виглядає таким чином:

Catch badnameexception When thename - String.Empty