Частина 10. PowerShell як мова програмування (Обробка помилок при виконанні команд)

Надійна обробка помилок у PowerShell: Забезпечення безпеки та стабільності програм

Окрім конструкцій try-catch, у PowerShell також є можливість використовувати команду -ErrorAction, яка дозволяє налаштувати реакцію на виникнення помилок під час виконання команд. Завдяки цій команді, програмісти можуть встановлювати різні рівні обробки помилок: від ігнорування до повного припинення виконання скрипту у разі виникнення помилки. Обробка помилок при виконанні команд у PowerShell є ключовим аспектом, який допомагає забезпечити безпеку та надійність програм та скриптів. Вміння ефективно обробляти помилки дозволяє програмістам більш точно контролювати виконання коду та забезпечити більш стабільну роботу програми в різних умовах. Таким чином, обробка помилок у PowerShell є важливим інструментом для програмістів, який допомагає забезпечити стабільність та надійність виконання програм та скриптів. Використання конструкцій try-catch та команди -ErrorAction дозволяє більш ефективно взаємодіяти з виникаючими помилками та забезпечити плавну та безпечну роботу програм у середовищі PowerShell.

Обробка помилок виконання команд

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

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

Крім того, один аспект обробки помилок в PowerShell відрізняє цю систему від інших мов програмування: помилки тут можуть бути критичними (переривають виконання команди) і некритичними (при їх виникненні виконання команди триває). Це пояснюється тим, що PowerShell використовує модель конвеєра команд для обробки об’єктів. При виникненні несмертельної помилки інформація про помилку записується на відповідний об’єкт, а поточна команда продовжує обробляти надходять до нього по трубопроводу об’єкти. Подібна помилка може виникнути, наприклад, при використанні командлета для копіювання багатьох файлів, один з яких зайнятий іншим додатком. Якщо виконується важлива операція, можливо, має сенс зупинити її після виникнення першої помилки (тоді така помилка буде критичною). Однак одну і ту ж помилку слід вважати критичної в одній ситуації і некритичної в іншій (в PowerShell є механізм, що дозволяє явно виставляти ці типи для помилок).

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

ErrorRecord Об’єкт і потік помилок

У PowerShell відомості про виникаючі помилки записуються в потік помилок, який відображається на екрані за замовчуванням, наприклад:

PS С:\Users\andrv> dir "Несуществующий каталог"
dir : Не удается найти путь "С: \Users\andrv\HecyujecTByioiuw4 каталог", т. к.
он не существует.
строка:1 знак:1
+ dir "Несуществующий каталог"
4- Categoryinfo : ObjectNotFound: (С: \Users\andrv\HecymecTByioiip™
каталог:String) [Get-Childltem],
ItemNotFoundException
+ FullyQualifiedErrorld : PathNotFound,Microsoft.PowerShell.Commands.
GetChi1ditemCommand

GetChildItemCorrmand в PowerShell має внутрішній номер 2, цей потік можна перенаправити в текстовий файл за допомогою спеціального оператора 2>, наприклад:

PS С:\Users\andrv> dir "Несуществующий каталог" 2> err.txt
Проверим теперь содержимое файла err.txt:
PS С:\Users\andrv> Get-Content .\err.txt
dir : He удается найти путь "С: \Users\andrv\HecyiuecTByKWw каталог", т. к.
он не существует.
строка:1 знак:1
+ dir "Несуществующий каталог" 2> err.txt
+ —----------- ---
+ Categoryinfo : ObjectNotFound: (С:\Users\andrv\HecyiuecTByKwra
каталог:String) [Get-Childltem] ,
11emNоt FoundExcept ion
+ FullyQualifiedErrorld : PathNotFound,Microsoft.PowerShell.Commands.
GetChildltemCommand

Як бачите, у файл err.txt записано повідомлення про помилку. Об’єкт ErrorRecord, який створюється при виникненні помилки, може бути збережений у змінній. Для цього використовується оператор, який перенаправляє потік помилок на стандартний вихідний потік (який має внутрішній номер 1). Наприклад:

PS С: \Users\andrv> $err = dir "Несуществующий каталог" 2>&1
PS С:\Users\andrv> $err.getType().fullName
System.Management.Automation.ErrorRecord
Проверим с помощью командлета Get-Member, какие свойства имеет объект типа
ErrorRecord:
PS С:\Users\andrv> $err | Get-Member -Type Property
TypeName: System.Management.Automation.ErrorRecord
Name MemberType Definition
Categoryinfo
ErrorDetails
Exception
Property
Property
Property
FullyQualifiedErrorld Property
Invocationinfo Property
Pipelinelterationlnfo Property
ScriptStackTrace
Targetobject
Property
Property
System.Management.Automation.Er...
System.Management.Automation.Er...
System.Exception Exception {get...
System.String FullyQualifiedErr...
System.Management.Automation.In...
System.Collections.ObjectModel....
string ScriptStackTrace {get;}
System.Object Targetobject {get...

Ці властивості пов’язані з помилками, що виникають, опис найважливіших з них наведено в табл. 10.1

Перевіримо вміст змінної $егг:

PS С:\Users\andrv> $err | Format-List * -Force
в System.Management.Automation.SessionStatelnternal.GetChildltems(String
path, Boolean recurse, UInt32 depth, CmdletProviderContext context
в Microsoft.PowerShell.Commands.GetChildltemCommand.ProcessRecord()
writeErrorStream
PSMessageDetails
Exception
: True
: System.Management.Automation.ItemNotFoundException:
He удается найти путь ”C:\Users\andrv\HecymecTByroiunn
каталог", т. к. он не существует.
Гпава 10. Обработка ошибок при выполнении команд 209
Targetobject
Categoryinfo
: С: \Users\andrv\HecynjecTByKWM каталог
: ObjectNotFound: (C: \Users\andrv\HecyuiecTByKwift
каталог:String) [Get-Childltem], ItemNotFoundException
FullyQualifiedErrorld : PathNotFound,
Microsoft.PowerShell.Commands.GetChildltemCommand
ErrorDetails
Invocationinfo
ScriptStackTrace
: System.Management.Automation.Invocationinfo
: в <ScriptBlock>, <Нет файла>: строка 1
Pipelinelterationlnfo : {0, 1}

Як бачимо, в нашому прикладі помилка відноситься до категорії PathNotFound, властивість TargetObj ect містить повний шлях, який використовувався командлетом dir для пошуку каталогу або файлу. Причиною помилки став ItemNotFoundException. Давайте дізнаємося, що містить властивість InvocationInfo:

PS С:\Users\andrv> $err.Invocationinfo
MyCommand
BoundParameters
UnboundArguments
ScriptLineNumber
OffsetlnLine
Historyld
ScriptName
Line
PositionMessage
: Get-Childltem
: {}
: {}
: 1
: 8
: 1
: $err = dir "Несуществующий каталог" 2>&1
: строка:1 знак:8
t $err = dir "Несуществующий каталог" 2>&1
+ --------—------------ ----- -------
PSScriptRoot
PSCommandPath
InvocationName
PipelineLength
PipelinePosition
Expectinglnput
Commandorigin
: dir
: 0
: 0
: False
: Internal
DisplayScriptPosition :

Властивість ScriptName тут не заповнена, тому що команда була введена безпосередньо в інтерактивному режимі оболонки, а не зі сценарію. Отже, ми вивчили структуру об’єкта ErrorRecord і довідалися, яку інформацію можна витягти з його властивостей. Нагадаємо, що ми отримали цей об’єкт шляхом перенаправлення потоку помилок у стандартний вихідний потік в одній конкретній команді. Зрозуміло, що для кожної команди, що виконується, повторювати ці маніпуляції ми не зможемо (стандартний вихідний потік може знадобитися для інших цілей) — необхідний зручніший механізм, що дозволяє визначати, чи виникла помилка, І звертатися До об’єкту ErrorRecord, ЩО відповідає ТІЙ АБО інший помилці. Подібні механізми реалізовані в PowerShell за допомогою кількох- 210 Частина II. PowerShell як мова програмування ких спеціальних змінних та параметрів, до розгляду яких ми зараз перейдемо.

Збереження об’єктів, які відповідають помилкам

PowerShell має спеціальну змінну $error, яка містить набір (масив) об’єктів ErrorRecord, які відповідають помилкам, що виникли в поточному сеансі. Максимальна кількість елементів у цій колекції встановлюється значенням змінної $MaximumErrorCount (256 за замовчуванням):

PS С:\Users\andrv> SMaximumErrorCount
256

Після заповнення масиву $error об’єкти для нових помилок замінять об’єкти, що відповідають старим помилкам. Виникнення кожної нової помилки призводить до зміщення елементів в масиві $error: об’єкт для останньої помилки ховається в першому елементі ($error об’єкт для попередньої помилки знаходиться в другому елементі ($error [1)”), і так далі. Повторимо помилку з попереднього розділу:

PS С:\Users\andrv> dir "Несуществуквдии каталог"
dir : Не удается найти путь "С: \Users\andrv\HecymecTByioiuHH каталог", т. к.
он не существует.
строка:1 знак:1
+ dir "Несуществующий каталог"
+ ~---- ~~----------- ~---
+ CategoryInfo : ObjectNotFound: (С: \Users\andrv\HecynjecTByioiw4
каталог:String) [Get-Chi ldltem],
ItemNotFoundException
+ FullyQualifiedErrorld : PathNotFound,Microsoft.PowerShell.Commands.
GetChildltemCommand

Тепер переконайтеся, що елемент $error [0] має тип ErrorRecord, і виведіть вміст цього елемента:

PS С:\Users\andrv> $error[0].getType().fullName
System.Management.Automation.ErrorRecord
PS C:\Users\andrv> $error[0]
dir : He удается найти путь "C:\Users\andrv\HecymecTByKWW каталог", т. к.
он не существует.
строка:1 знак:1
+ dir "Несуществующий каталог"
+ Categoryinfo : ObjectNotFound: (С: \Users\andrv\HecymecTByioiW4
каталог:String) [Get-Chi ldltem],
ItemNotFoundException
+ FullyQualifiedErrorld : PathNotFound,Microsoft.PowerShell.Commands.
GetChildltemCommand
Естественно, МЫ можем обращаться КО всем свойствам объекта ErrorRecord:
PS С:\Users\andrv> $error[0].exception
He удается найти путь "С: \Users\andrv\HecyiijecTByKWM каталог", т. к.
он не существует.
PS С:\Users\andrv> $error[0].invocationinfo
MyCommand
BoundParameters
UnboundArguments
ScriptLineNumber
OffsetlnLine
Historyld
ScriptName
Line
PositionMessage
PSScriptRoot
PSCommandPath
InvocationName
PipelineLength
PipelinePosition
Expectinglnput
Commandorigin
DisplayScriptPosition
Get-Childltem
{}
{}
1
1
10
dir "Несуществующий каталог"
строка:1 знак:1
+ dir "Несуществующий каталог"
dir
0
0
False
Internal
PS С:\Users\andrv> $error[0].targetobject
C: \Users\andrv\HecyujecTByKWM каталог

Для перехоплення помилок певної команди без перенаправлення помилок у стандартний вихідний потік можна скористатися стандартним параметром -Errorvariable, який визначений у всіх командах PowerShell. Наприклад, у наступній команді інформація про помилки буде записуватися в змінну $errs (зверніть увагу, що при заданні значення параметра -Errorvariable знак $ перед ім’ям змінної вказувати не потрібно):

PS С:\Users\andrv> dir "Каталог 1", "Каталог 2" -Errorvariable errs
dir : Не удается найти путь "С:\Users\andrv\KaTanor 1", т. к. он не существует,
строка:1 знак:1
+ dir "Каталог 1", "Каталог 2" -Errorvariable errs
+ Categoryinfo : ObjectNotFound: (С:\изегз\апЬгу\Каталог 1:String)
[Get-Childltem], Item NotFoundException
+ FullyQualifiedErrorld : PathNotFound,Microsoft.PowerShell.Commands.
GetChi1d11emCommand
dir : He удается найти путь "С: \иэегз\апЬ^\Каталог 2", т. к. он не существует,
строка:! знак:1
+ dir "Каталог 1", "Каталог 2" -ErrorVariable errs
4- Categoryinfo : ObjectNotFound: (С:\Users\andrv\Kaтaлoг 2:String)
[Get-Childltem], Item NotFoundException
+ FullyQualifiedErrorld : PathNotFound,Microsoft.PowerShell.Commands.
GetChi1dItemCommand
При выполнении данной команды возникают две некритические ошибки, т. е.
переменная $errs должна быть массивом, содержащим два объекта ErrorRecord.
Проверим это:
С:\Users\andrv> $errs.count
2
С:\Users\andrv> $errs[O].getType().fullName
System.Management.Automation.ErrorRecord
C:\Users\andrv> $errs[l].getType().fullName
Systern.Management.Automation.ErrorRecord
C:\Users\andrv> $errs[0].targetobject
C:\Users\andrv\KaTanor 1
C:\Users\andrv> $errs[l].targetobject
C:\Users\andrv\Kaтaлoг 2

Як бачимо, при вказанні параметра Errorvariable повідомлення про помилки, що виникають, як і раніше виводяться на екран. Для придушення цих повідомлень потрібно перенаправити потік помилок на порожній пристрій $nuii, наприклад:

PS С:\Users\andrv> dir "Каталог 1", "Каталог 2" -ErrorVariable errs 2> $null
С:\Users\andrv>
На экран ничего не выводится, а в переменную $errs по-прежнему записываются
два объекта:
PS С:\Users\andrv> $errs.count
2
При этом объекты, соответствующие ошибкам, записываются и в переменную
$еггог:
PS С:\Users\andrv> $error[0]
dir : Не удается найти путь "С:\Users\andrv\Kaтaлoг 2", т. к. он не существует,
строка:1 знак:1
+ dir "Каталог 1", "Каталог 2" -ErrorVariable errs 2> $null
+ —,— —----- ---- _ ----------------- _____
+ Categoryinfo : ObjectNotFound: (С:\Users\andrv\Kaтaлoг 2:String)
[Get-Childltem], Item NotFoundException
+ FullyQualifiedErrorld : PathNotFound,Microsoft.PowerShell.Commands.
GetChildltemCommand
PS C:\Users\andrv> $error[l]
dir : He удается найти путь "С:\Users\andrv\Kaтaлoг 1", т. к. он не существует,
строка:! знак:1
+ dir "Каталог 1", "Каталог 2" -Errorvariable errs 2> $null
+ -- -------------------- -—~~~~
+ Categoryinfo : ObjectNotFound: (С:\Users\andrv\Kaтaлoг 1:String)
[Get-Childltem], Item NotFoundException
+ FullyQualifiedErrorld : PathNotFound,Microsoft.PowerShell.Commands.
GetChildltemCommand

Моніторинг виникнення помилок

Під час інтерактивної роботи в оболонці PowerShell ми дізнаємося про помилку повідомлення на екрані. Після цього ми можемо проаналізувати об’єкт $error[0] і дізнатися всю інформацію про помилку. Але як дізнатися про помилку всередині сценарію? Виявляється, в PowerShell є логічна змінна $?, яка дорівнює True, якщо остання операція завершена успішно, і дорівнює False, якщо під час виконання останньої операції виникли будь-які помилки. Наприклад, якщо виконати командлет Get-item для існуючого каталогу, то значення змінної $? дорівнюватиме True:

PS С:\Users\andrv> Get-Item С:\
Каталог:
Mode LastWriteTime Length Name
d—hs- 01.08.2021 12:57 C:\
PS C:\Users\andrv> $?
True
Если же выполнить командлет Get-item для несуществующего каталога, то значение переменной $? будет равно False:
PS С:\Users\andrv> Get-Item С:\АБВГГ
Get-Item : Не удается найти путь "С:\АБВГГ", т. к. он не существует.
строка:1 знак:1
+ Get-Item С:\АБВГГ
+ Categoryinfo : ObjectNotFound: (С:\АБВГГ:String) [Get-Item],
ItemNotFoundException
+ FullyQualifiedErrorld : PathNotFound,Microsoft.PowerShell.Commands.
Get I temCommand
PS C:\Users\andrv> $?
False

Для зовнішніх команд Windows та сценаріїв PowerShell визначено поняття коду повернення (нагадаємо, що для сценаріїв PowerShell цей код можна встановити за допомогою інструкції Exit). В операційній системі код повернення останньої команди доступний через змінне середовище %errorlevel%; в оболонці PowerShell цей код повернення зберігається у спеціальній змінній $lastexitcode. При цьому якщо код повернення дорівнює нулю, то змінної $? надається значення True. Якщо ж код повернення не дорівнює нулю, то вважається, що при виконанні цієї команди сталася помилка і змінною $? надається значення False. Як приклад виконаємо команду інтерпретатора cmd.exe, яка встановлює нульовий код повернення. Для цього можна запустити cmd.exe з ключем /с (виконати команду та завершити роботу інтерпретатора) та вказати для виконання команду exit 0:

PS С:\Users\andrv> cmd /с exit О
Проверим значения переменных $lastexitcode и $?:
PS С:\Users\andrv> $LASTEXITCODE
0
PS С:\Users\andrv> $?
True
Теперь выполним команду интерпретатора cmd.exe с ненулевым кодом возврата
(пусть, например, код возврата равен 10):
PS С:\Users\andrv> cmd /с exit 10
Вновь проверим переменные $lastexitcode и $?:
PS С:\Users\andrv> $?
False
PS С:\Users\andrv> $LASTEXITCODE
10
Итак, мы убедились, что переменными $lastexitcode и $? можно пользоваться для
обнаружения ошибок при выполнении сценариев PowerShell.

Режими обробки помилок

На початку цього розділу ми говорили про те, що помилки в PowerShell діляться на критичні (переривають виконання команди) і некритичні (при їх виникненні виконання команди триває). При цьому, в залежності від ситуації, іноді може знадобитися ставитися до некритичних помилок як до критичних і навпаки. Аналогічна зміна типу помилок реалізовано в PowerShell з використанням різних режимів обробки помилок (табл. 10.2).

Щоб встановити бажаний режим обробки помилок, призначте відповідне значення змінній $ErrorActionPreference, наприклад: $ErrorActionPreference ” Si1ent1yContinue “

При цьому режим продовження без видачі повідомлення про помилку торкнеться всіх команд.

Таблиця 10.2. Режими обробки помилок в PowerShell

Якщо потрібно переключити режим обробки помилок тільки для одного командлета, при його виклику необхідно вказати відповідну константу символів як значення загального параметра -ErrorAction (або скорочено ea), наприклад:

PS С:\Users\andrv> Get-Item "несуществующий файл" -ErrorAction SilentlyContinue

Обробка критичних помилок (винятків)

Нагадаємо, що критичні помилки в PowerShell – це помилки, через які команда припиняє виконання. У традиційних мовах програмування такі помилки зазвичай називають винятками. У PowerShell можна ловити критичні помилки, тобто виконувати певні дії при їх виникненні, використовуючи два твердження: Trap і Try/Catch/Fina11y.

Інструкція по трепінгу

Оператор Trap був реалізований в першій версії PowerShell і був тоді єдиним інструментом для обробки винятків.

Існує два можливі варіанти синтаксису для Trap:

trap [тип_исключения] {блок_кода}
ИЛИ
trap {блок_кода}

У першому випадку блок коду буде виконуватися тільки при виникненні виключення певного типу (наприклад, щоб вловити помилки, що виникають при спробі ділення на нуль, в якості типу виключення потрібно вказати DivideByZeroException), а в другому – при виникненні будь-якого виключення. Наведемо приклад.

PS С:\Users\andrv> trap {"Исключение перехвачено!"} $п=0; 1/$п; "п=$п"
Исключение перехвачено!
Попытка деления на нуль.
строка:1 знак:40
+ trap {"Исключение перехвачено!"} $п=0; 1/$п; "п=$п"
+ ~~~~
+ Categoryinfo : NotSpecified: (:) [], RuntimeException
+ FullyQualifiedErrorld : RuntimeException
n=0

У цьому випадку при обчисленні виразу 1/$n відбувається виняток (спроба ділення на нуль) і управління передається в тіло оператора Trap, де виводиться рядок Exception catchht!. Переконайтеся, що відповідний помилці об’єкт записаний в $error масив (саме тому на екрані tayuke відображається стандартне повідомлення про помилку):

PS С:\Users\andrv> $error[0]
Попытка деления на нуль.
строка:1 знак:40
+ trap {"Исключение перехвачено!"} $n=0; l/$n; "п=$п"
+ --- -
+ Categoryinfo : NotSpecified: (:) [], RuntimeException
+ FullyQualifiedErrorld : RuntimeException

Зверніть увагу, що після виконання тіла інструкції Trap управління в нашому прикладі передається команді, яка слідує інструкції, яка викликала помилку. Насправді це не завжди так. Якщо вийти з движка за допомогою оператора Break, інші команди виконуватися не будуть:

PS С:\Users\andrv> trap {"Исключение перехвачено!"; break} $п=0; 1/$п; "п=$п"
Исключение перехвачено!
Попытка деления на нуль.
строка:1 знак:47
+ trap {’’Исключение перехвачено!”; break} $n=0; l/$n; "п=$п"
+
+ Categoryinfo : NotSpecified: (:) [],
ParentContainsErrorRecordException
+ FullyQualifiedErrorld : RuntimeException
Как видим, здесь отсутствует вывод на экран строки ”п=0”. Если выход из обработчика исключения производится С ПОМОЩЬЮ инструкции Continue, то оставшиеся
команды выполняются:
PS С:\Users\andrv> trap {"Исключение перехвачено!"; $_.Exception ; continue}
$n=0; l/$n; "n=$n"
Исключение перехвачено!
Попытка деления на нуль.
п=0

Цей приклад також показує, що при обробці винятку доступ до відповідного об’єкта, як зазвичай, здійснюється за допомогою змінної $. Якщо вийти з обробника винятків звичайним способом (без використання операторів Break або Continu), то подальша поведінка визначається значенням змінної $ErrorActionPreference, розглянутої в попередньому розділі. Наприклад, наведений нижче приклад перериває виконання команди після обробки винятку:

PS С:\Users\andrv> $ErrorActronPreference = "Stop"
PS C:\Users\andrv> trap {"Исключение перехвачено!"} $n=0; l/$n; "n=$n"
Исключение перехвачено!
Попытка деления на нуль.
строка:1 знак:40
+ trap {’’Исключение перехвачено!”} $n=0; l/$n; "п=$п”
-I- Categoryinfo : NotSpecified: (:) [],
ParentContainsErrorRecordException
+ FullyQualifiedErrorld : RuntimeException
Изменим теперь режим обработки ошибок и еще раз выполним те же команды
после инструкции Trap:
PS С:\Users\andrv> $ErrorActionPreference = "SilentlyContinue"
PS C:\Users\andrv> trap {"Исключение перехвачено!"} $n=0; l/$n; "n=$n"
Исключение перехвачено!
n=0
В данном случае стандартное сообщение об ошибке на экран не выводится и после
обработки исключения выполняется следующая команда.

Інструкція Try/Catch/Finally

Інструкція Try/Catch/Finally, аналоги якої є в багатьох мовах програмування, підтримується з другої версії PowerShell. Це більш зручний і звичний варіант обробки винятків, ніж інструкція Trap. У блоці Try записуються команди та вирази, для яких ми хочемо перехоплювати виникнення критичних помилок. Цьому блоку має відповідати Хоча б один блок Catch АБО Finally. БЛОКІВ Catch МОЖЕ бути КІЛЬКА, В НИХ можуть перевірятись типи винятків, які потрібно обробити. Якщо блок Finally вказано, то код у ньому буде виконано в будь-якому випадку, незалежно від виникнення виключення. Зазвичай Finally поміщають код для звільнення використаних ресурсів (закриття підключення до бази даних, очищення сеансу віддаленого доступу тощо).

Наведемо приклад обробки виключення без перевірки його типу:

PS С:\Users\andrv> try {
» 1
» 2
» 3/0
» 4
» } catch {
» "Ошибка: $_"
» } finally {
» 'Завершающий блок'
» }
1
2
Ошибка: Попытка деления на нуль.
Завершающий блок

У блоці Try тут виникає помилка при спробі розділити число на нуль, а управління передається в блок Catch, де об’єкт помилки доступний під ім’ям $. Після виконання блоку Catch виконуються команди з блоку Fina11y.

Підсумки

• У PowerShell існує два типи помилок: критична, яка перериває виконання команди, і некритична, коли команда триває.

• При виникненні помилки система генерує об’єкт типу ErrorRecord, який містить інформацію про помилку.

• Об’єкти з інформацією про помилки спрямовуються до стандартного потоку помилок, вміст якого відображається на екрані за замовчуванням.

• Об’єкти ErrorRecord, які відповідають помилкам, що виникають у поточному сеансі, автоматично зберігаються в спеціальному масиві $error. Об’єкт для останньої помилки міститься в $error [0].

• Об’єкти, які відповідають помилкам, можна зберегти в інші змінні, вказавши їх імена в стандартному параметрі -ErrorVariab1e.

• У змінній $? Система зберігає статус завершення останньої команди. A: Код повернення утиліти або скрипта зовнішньої консолі записується на змінну $LASTEXITCODE.

• PowerShell підтримує кілька режимів обробки командних помилок, які можна перемикати за допомогою змінної $ErrorActionPreference та загального параметра -ErrorAction.

• Критичні помилки (винятки) можна обробляти за допомогою операторів Trap та Try/Catch/Fina11y.

Дякуємо нашій команді волонтерів за надану інформацію з відкритих джерел.