Обзор технологии Microsoft Windows PowerShellMicrosoft ® 1 Назначение PowerShell 2 Установка Windows PowesShell 6 Назначение PowerShell 7



Скачать 13.55 Mb.
страница26/27
Дата29.11.2016
Размер13.55 Mb.
Просмотров5699
Скачиваний0
ТипОбзор
1   ...   19   20   21   22   23   24   25   26   27

Обработка ошибочных ситуаций


Несмотря на то, что вам придется фиксировать и устранять некоторые ошибки, например, опечатки, во время написания сценария, некоторые ошибки можно предусмотреть заранее. Например, ошибка, возникающая из-за того, что файл или сервер недоступен, относится к тем ошибкам, о возможности возникновения которых можно догадаться заранее, но которые нельзя зафиксировать или предотвратить. Решением в данном случае станет написание сценария, который позволит выявить и исправить такие ошибки.

В сценарии a Windows PowerShell выделяют три большие категории ошибок:

• Синтаксические ошибки, которые, как правило, являются результатом опечаток или неправильного написания.

• Логические ошибки, которые означают, что сценарий выполняется верно, но результаты получаются не те, которые были запланированы.

• Ошибки выполнения, которые можно предусмотреть заранее, но нельзя исправить заранее (например, недоступность удаленного компьютера).

Синтаксические ошибки проще всего выявить и предупредить. Сообщения об ошибках обычно направляют вас в нужное место – вам остается лишь пристально взглянуть на неправильно набранное слово, определить ошибку и устранить ее. Логические ошибки являются более сложными и требуют настройки сценария – об этом вы узнаете чуть позже. Логические ошибки обычно возникают, когда переменная или свойство имеет значение, несущее не ту информацию, которую вы ожидаете. Например, вы предполагаете, что свойство DriveType содержит строку Removable, а в действительности оно содержит числовое значение «5». И, наконец, ошибки выполнения по степени сложности решения находятся примерно посередине между синтаксическими и логическими. Ошибки выполнения не всегда можно предсказать заранее. Например, вы можете написать скрипт для подключения к удаленному компьютеру, но при попытке подключения выяснится, что у вас нет на это разрешения. На этом уроке мы остановимся на ошибках выполнения, которые не всегда можно предупредить, но можно предугадать возможность их возникновения во время написания скрипта.


$ErrorActionPreference


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

Get-WmiObject Win32_Service –computer Server1,Server2,Server3

Предположим, что во время запуска команды Server2 оказался в режиме оффлайн. Командлет успешно установил соединение с Сервером 1, но попытка подключения к Серверу 2 оказалась неудачной. Это непрерывающая ошибка. Командлет не может выполнить действие для Сервера 2, но он не прекращает работу и переходит к Серверу 3. Когда командлет сталкивается с ошибкой такого типа, он проверяет, что можно предпринять для ее решения. Информация о действиях, предпринимаемых для решения бесконечных ошибок, хранится во встроенной в оболочку переменной $ErrorActionPreference. Эта переменная может принимать одно из четырех значений:

• Continue является значением по умолчанию и дает командлету инструкцию: выдать сообщение об ошибке и продолжить работу.

• Stop принуждает командлет превратить непрерывающую ошибку в прерывающее исключение, в результате чего выполнение командлета полностью прекращается.

• SilentlyContinue дает командлету инструкцию продолжать работу без отображения сообщения об ошибке.

• Inquire – дает командлету инструкцию обратиться к пользователю с запросом, чтобы пользователь мог самостоятельно выбрать, что следует сделать – остановить работу или продолжить.

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

Порочная практика


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

$ErrorActionPreference = "SilentlyContinue"

Обычно они делают это потому, что используют такой командлет, как Get-WmiObject, с помощью которого они могут предусмотреть возникновение ошибок, поэтому, сообщения об ошибках им не нужны. Однако добавление вышеуказанной команды в начало сценария отменяет появление сообщений об ошибках для всего скрипта. Зачастую при выполнении скрипта возникают ошибки совсем другого рода, о которых администратор не узнает, так как сообщения об ошибках отключены. В результате скрипт работает не так, как планировалось, и а его настройку уходит масса времени, так как без сообщения об ошибках весьма сложно определить, в каком месте необходимо внести изменения в сценарий. Существует очень мало ситуаций, в которых сообщения об ошибках не нужны вообще. Поэтому, если вы решили отключить уведомления, лучше сделать это для одного, конкретного командлета.


–ErrorAction


Все командлеты Windows PowerShell поддерживают ряд общих параметров, которые обрабатываются непосредственно самой оболочкой, и которые разработчик командлетов не должен прописывать вручную. Эти параметры не перечисляются в справочнике для каждого командлета, их список можно увидеть в разделе Common Parameters. Прочитать информацию о них можно, набрав команду:

Help about_commonparameters

Один из общих параметров - это –ErrorAction, имеющий псевдоним EA. Этот параметр может принимать те же четыре значения, что и переменная $ErrorActionPreference. Однако, в отличие от этой переменной, данный параметр осуществляет выявление и отображение ошибок только для одного командлета. Поэтому, если вы используете командлет, например, Get-WmiObject, вы можете отключить уведомления об ошибках именно для этого командлета с использованием параметра –ErrorAction или –EA:



Gwmi Win32_Service –computer Server1,Server2,Server3

EA SilentlyContinue


Перехват ошибок


Вы можете дать оболочке указание уведомлять о прерывающих исключениях и запускать команды в ответ на эти ошибки. Это называется «перехват ошибок» и означает, что вы самостоятельно определяете, какое действие предпринять в ответ на возникшую ошибку, а не доверяете оболочке произвести действие по умолчанию.

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

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

Если вы используете –ErrorAction Inquire, перехватываемое исключение генерируется только в том случае, если пользователь выбирает опцию «остановить командлет». После того, как вы дали командлету инструкцию превращать непрерывающие ошибки в прерывающие перехватываемые исключения посредством –EA Stop, у вас есть два варианта перехвата ошибки: с помощью конструкции Trap или конструкции Try…Catch

Прежде, чем мы перейдем к конструкциям Trap и Try…Catch, вспомните, что вы знаете об областях действия в Windows PowerShell.

Сама оболочка – это глобальная область действия. Каждый скрипт, который вы запускаете, создает свою собственную область действия. Функции (которые мы рассмотрим чуть позже) тоже содержатся в своих областях действия. Поэтому, если вы выполняете сценарий, который содержит функцию, вы имеете дело с деревом областей действия, которое выглядит примерно так:

• Глобальная область действия

• Область действия скрипта

• Область действия функции

Область действия функции является дочерней по отношению к скриптовой, а скриптовая, в свою очередь, является дочерней по отношению к глобальной. Если прерывающее исключение происходит внутри функции, оболочка сначала проверяет, собираетесь ли вы перехватить это исключение внутри этой же области, т.е. внутри функции. Если у вас нет способа сделать это, оболочка покидает область действия функции и переносит прерывающее исключение в родительскую область действия, в данном случае в скриптовую. С точки зрения скрипта, функция сама сгенерировала это исключение, поэтому, оболочка проверяет, есть ли внутри скрипта инструменты для того, чтобы перехватить и исправить исключение. Если таких инструментов не обнаружено, оболочка покидает область действия скрипта и обращается к глобальной области действия. С точки зрения глобальной области действия, исключение было сгенерировано всем скриптом, и оболочка начинает искать инструменты для перехвата и исправления ошибки в глобальной области действия. Это может показаться довольно сложным, но очень важно решить, какие действия предпринять в отношении ошибки. Говоря в общем, вы должны стараться перехватить и исправить ошибку в той области действия, в которой она возникла. Например, если функция содержит командлет Get-WmiObject, и вы хотите перехватить и исправить ошибки для этого командлета, конструкция перехвата ошибок должна быть включена в функцию. Таким образом, оболочке не придется выходить за пределы области действия функции для исправления ошибки.


Trap


Конструкция для перехвата ошибок обычно указывается в скрипте перед исключением, возникновение которого вы предусматриваете. Простая конструкция может выглядеть примерно так:

trap {

write-host "Exception trapped!" -fore yellow -back black

continue

}

get-wmiobject win32_process -comp NotOnline -ea stop

В конце конструкции вы можете указать одно или два ключевых слова:

• Continue – продолжает выполнение команды, которая указана в скрипте после исключения, не выходя за пределы текущей области действия.

• Break – выходит за пределы текущей области действия и ищет средства для перехвата ошибки и ее исправления в родительской области действия.

Например, рассмотрим короткий скрипт:

trap {

write-host "Exception trapped in the script"

-fore green -back black

continue

}

function test {

trap {

write-host "Exception trapped in the function"

-fore yellow -back black

break

}

write-host "I am inside the function"

get-wmiobject win32_process -comp NotOnline -ea stop

write-host "I am still inside the function"

}

write-host "Running the function"

test

write-host "Finished running the function"

Ошибка возникает в командлете Get-WmiObject. Так как перехват ошибки указан в области действия функции, этот перехват выполняется. Перехват заканчивается ключевым словом break, поэтому оболочка выходит за пределы области действия функции и передает ошибку в родительскую область. Перехват определен и здесь, поэтому он выполняется. Перехват заканчивается ключевым словом continue, поэтому оболочка переходит к выполнению команды, указанной после перехвата. С точки зрения скрипта, ошибка произошла в функции test, поэтому выполнение команды продолжается в этой же области действий. Выходные данные скрипта будут выглядеть так:



Running the function

I am inside the function

Exception trapped in the function

Exception trapped in the script

Finished running the function

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

Ниже вы видите тот же самый скрипт с одной небольшой разницей: Перехват внутри функции сейчас заканчивается ключевым словом continue, а не break:

trap {

write-host "Exception trapped in the script"

-fore green -back black

continue

}

function test {

trap {

write-host "Exception trapped in the function"

-fore yellow -back black

continue

}

write-host "I am inside the function"

get-wmiobject win32_process -comp NotOnline -ea stop

write-host "I am still inside the function"

}

write-host "Running the function"

test

write-host "Finished running the function"

Выходные данные сейчас выглядят так:



Running the function

I am inside the function

Exception trapped in the function

I am still inside the function

Finished running the function

Вы поняли, почему? Когда произошла ошибка, был выполнен перехват внутри функции. Однако эта команда заканчивалась ключевым словом continue, поэтому, оболочка не вышла за пределы области действия функции и продолжила выполнений следующей команды. Поэтому, на этот раз отобразилась строчка I am still inside the function. Функция была выполнена до конца, а ошибка не была передана в скрипт. Поэтому, перехват в скрипте не был выполнен.

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

Конструкция перехвата, с которой вы только что познакомились, была общей, то есть, она подходит для любого типа прерывающих исключений. Windows PowerShell также позволяет определять перехват особых видов исключений, но для этого вы должны знать определенные типы классов исключений .NET Framework. Например:



trap [System.Management.Automation.CommandNotFoundException]

{"Command error trapped"}

Этот перехват выполняется только для исключений типа System.Management.Automation.CommandNotFoundException. Оболочка позволяет указывать несколько конструкций для перехвата, каждая из которых предназначена для конкретного типа исключений. Это один из способов выбирать разные инструменты для решения разных проблем. Однако определить нужное имя класса .NET Framework может оказаться сложно.

Также обратите внимание, что перехват – это отдельная область действия, как и функция. Перехват может получать доступ к переменным за пределами своей области действия, по общим правилам. Однако любые переменные, которые создаются или устанавливаются перехватом, относятся только к нему. Если вы используете перехват, чтобы изменить переменную, расположенную в родительской для него области действия, используйте командлет Set- Variable с параметром –scope.

Try…. Catch


Конструкция Try…Catch является более простой в использовании, чем конструкция Trap. Типичная конструкция такого типа выглядит так:

try {

gwmi win32_service -comp notonline -ea stop

} catch {

write-host "Error!"

}

Блок Try определяет команду, при выполнении которой, как вы предполагаете, может произойти ошибка, и для которой вы задали ErrorAction команды Stop. Если ошибка произошла, начинает выполняться код, указанный внутри блока Catch.

Так же, как и в случае с конструкцией Trap, вы можете указать несколько блоков Catch, каждый из которых будет выявлять определенный тип ошибок. Чтобы узнать больше об этой технике, запустите Help about_try_catch_finally.

После того, как выполнение кода внутри блока Catch закончилось, начинается выполнение команды, указанной после блока Try…Catch. Также вы можете задать блок Finally:



try {

gwmi win32_service -comp notonline -ea stop

} catch {

write-host "Error!"

} finally {

write-host "This executes either way"

}

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


Извлечение ошибок


При использовании конструкций Trap и Try вам, возможно, понадобится доступ к тому исключению, которое стало причиной запуска этой конструкции. Существует два способа добиться этого. Встроенная переменная $error содержит ошибки, встречающиеся в оболочке. $Error[0] – это последняя ошибка, $Error[1] – предпоследняя и.т.д. Также вы можете использовать параметр -ErrorVariable (или –EV) для того чтобы выявить ошибку, сгенерированную этим командлетов в переменную. Например:

Get-Content does-not-exist.txt –EA Stop –EV myerr

Обратите внимание, что перед именем переменной myerr в данном контексте не используется символ $. Если происходит ошибка, командлет помещает информацию о ней в указанную переменную. Вы можете использовать ее следующим образом:



try {

gwmi win32_service -comp notonline -ea stop -ev myerr

} catch {

$myerr | out-file c:\errors.txt -append

}

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




Поделитесь с Вашими друзьями:
1   ...   19   20   21   22   23   24   25   26   27


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал