har du någonsin köra ett skript eller en PowerShell cmdlet och få konfronteras med en skrikande vägg av text-i rött – som den som visas nedan?

fel kan bli överväldigande och förvirrande. Och mest av allt är fel ofta svåra att läsa, vilket gör det omöjligt att bestämma vad och var skriptet gick fel nära omöjligt.,

lyckligtvis har du några alternativ i PowerShell för att göra detta bättre genom felhantering. Med hjälp av felhantering kan fel filtreras och visas på ett sådant sätt att det är lättare att förstå. Och förstå felet gör det enkelt att lägga till mer logik för felhantering.

i den här artikeln kommer du att lära dig om fel i PowerShell och hur de kan avlyssnas för att utföra felhantering med PowerShell Try Catch block (och finally block).,

förstå hur fel fungerar i PowerShell

innan du dyker in i felhantering, låt oss först täcka några begrepp kring fel i PowerShell. Att förstå fel kan leda till bättre felhanteringsstrategier.

$Error Automatic Variable

i PowerShell finns det många automatiska variabler, och en av dem är$Error automatisk variabel. PowerShell använder variabeln$Error för att lagra alla fel som uppstår i sessionen., Variabeln$Error är en rad fel sorterade efter den senaste.

När du först öppnar en PowerShell-session är variabeln$Error tom. Du kan kontrollera det så genom att ringa variabeln $Error.

som du kan se startar variabeln$Error tom., Men när ett fel genereras kommer felet att läggas till och lagras i variabeln $Error.

i exemplet nedan genereras felet genom att medvetet få ett servicenamn som inte finns.

PS> Get-Service xyzPS> $ErrorPS> $Error.Count

som du kan se från utgången ovan, har det genererade felet lagts till variabel.,

$ – Felvariabeln innehåller en samling fel som genereras i PowerShell-sessionen. Varje fel kan komma åt genom att ringa sin array position. Det senaste felet kommer alltid att vara på index 0.

till exempel kan det senaste felet hämtas med$Error.

objektegenskaperna $Error

eftersom allt i PowerShell är ett objekt är variabeln$Error ett objekt och objekt har egenskaper., Genom att flytta $Error – variabeln till Get-Member cmdlet, bör du se listan över tillgängliga egenskaper.

$Error | Get-Member

för att fastställa orsaken till felet kan du visa innehållet i använder kommandot nedan.,

$Error.InvocationInfo

Nu kan du göra detsamma med de andra egenskaperna och upptäcka vilken annan information du kan hitta!

avsluta fel

avsluta fel stoppa körningsflödet när det påträffas av PowerShell vs icke-avslutande fel. Det finns flera sätt ett avslutande fel kan uppstå. Ett exempel är när du ringer en cmdlet med en parameter som inte existerar.,

som du kommer från skärmdumpen nedan, när kommandot Get-Process notepad körs, är kommandot giltigt och detaljerna i anteckningsblocket visas.

men när en parameter som inte finns används som Get-Process notepad -handle 251 visar cmdlet ett fel som Get-Process notepad -handle 251. id = ”70d5672a0e” > parametern är inte giltig. Sedan lämnar cmdlet utan att visa detaljerna inotepad – processen.,

icke-avslutande fel

icke-avslutande fel är fel som inte stoppar utförandet av skriptet eller kommandot. Till exempel, kolla in koden nedan. Den här koden får listan över filnamn från fillistan.txt-filen. Sedan går skriptet igenom varje filnamn, läser innehållet i varje fil och matar ut det på skärmen.

$file_list = Get-Content .\filelist.txtforeach ($file in $file_list) { Write-Output "Reading file $file" Get-Content $file}

fillistens innehåll.,txt-filen är filnamnen som visas i listan nedan.

File_1.logFile_2.logFile_3.logFile_4.logFile_5.logFile_6.logFile_7.logFile_8.logFile_9.logFile_10.log

men vad händer om File_6.fanns inte loggen egentligen? När du kör koden förväntar du dig att ett fel kommer att hända eftersom skriptet inte kan hitta File_6.logga. Du ser en liknande utgång som visas nedan.

som du kan se från skärmdumpen av resultatet ovan kunde skriptet läsa de första fem filerna i listan, men när det försökte läsa filen File_6.,txt, ett fel returneras. Skriptet fortsatte sedan att läsa resten av filerna innan de slutade. Det slutade inte.

variabeln $ErrorActionPreference

hittills har du lärt dig om de avslutande och icke-avslutande felen och hur de skiljer sig från varandra. Men visste du att ett icke-avslutande fel kan tvingas behandlas som ett avslutande fel?

PowerShell har ett koncept som heter preferensvariabler. Dessa variabler används för att ändra hur PowerShell beter sig på många olika sätt. En av dessa variabler kallas $ErrorActionPreference.,

variabeln$ErrorActionPreference används för att ändra hur PowerShell behandlar icke-avslutande fel. Som standard är värdet $ErrorActionPreference inställt på Continue. Ändra värdet på variabeln$ErrorActionPreference tillSTOPtvingar PowerShell att behandla alla fel som att avsluta fel.

använd koden nedan för att ändra värdet$ErrorActionPreference.,

$ErrorActionPreference = "STOP"

om du vill veta mer om andra giltiga variabelvärden för $ErrorActionPreference kan du besöka PowerShell ErrorActionPreference.

Se nu tillbaka till exemplet som används i avsnittet icke-avslutande fel i den här artikeln. Skriptet kan ändras för att inkludera ändringen i$ErrorActionPreference som koden som visas nedan:

att köra den ändrade koden ovan kommer att bete sig annorlunda än tidigare när värdet$ErrorActionPreference är inställt på standardvärdet förContinue.,

som du kan se från skärmdumpen av resultatet ovan kunde skriptet läsa de första fem filerna i listan, men när den försökte läsa filen file_6.txt, ett fel returneras eftersom filen inte hittades. Sedan avslutas skriptet, och resten av filerna läses inte.,

värdet$ErrorActionPreference är endast giltigt i den aktuella PowerShell-sessionen. Det återställs till standardvärdet när en ny PowerShell-session startas.

Erroraction Common Parameter

om värdet$ErrorActionPreference tillämpas på PowerShell-sessionen gäller parameternErrorAction för alla cmdlet som stöder vanliga parametrar. ParameternErrorActionaccepterar samma värden som variabeln $ErrorActionPreference gör.,

parametervärdetErrorAction har företräde framför värdet$ErrorActionPreference.

låt oss gå tillbaka och använda samma kod i föregående exempel. Men den här gången läggs ErrorAction – parametern till Get-Content – raden.

Efter att ha kört den ändrade koden ser du att även om $ErrorActionPreference är inställt på Continue avslutas skriptet när det uppstod ett fel., Skriptet avslutades eftersom parametervärdet-ErrorAction IGet-Content är inställt påSTOP.

använda PowerShell försök fånga Block

vid denna punkt har du lärde dig om PowerShell-fel och hur parametrarna $ErrorActionPreference och ErrorAction fungerar., Nu är det dags att du lär dig om de bra sakerna-PowerShellTry Catch Finally block.

PowerShelltry catch block (och valfriafinally block) är ett sätt att kasta ett nät runt en bit kod och fånga eventuella fel som återvänder.

koden nedan visar syntaxen förTry – satsen.

try { <statement list>}catch *]{ <statement list>}finally { <statement list>}

Try blocket innehåller koden som du vill att PowerShell ska ”prova” och övervaka för fel., Om koden i Try – blocket stöter på ett fel läggs felet till $Error – variabeln och skickas sedan till Catch – blocket.

Catch – blocket innehåller de åtgärder som ska utföras när det tar emot ett fel frånTry – blocket. Det kan finnas fleraCatch block i ettTry – uttalande.

Finally blocket innehåller den koden som kommer i slutet avTry – satsen., Det här blocket körs om ett fel inte har tagits bort eller inte.

fånga icke-specifika fel (Catch-All)

en enkelTry uttalande innehåller enTry och enCatch block. Finally – blocket är valfritt.

för att till exempel fånga ett icke-specifikt undantag bör parameternCatch vara tom. Exempelkoden nedan använder samma skript som användes i sektionen $ErrorActionPreference variabel men ändras för att använda blocken Try Catch.,

som du kan se från koden nedan, är foreach – satsen bifogad i Try – blocket. Då innehåller ettCatch – block koden för att visa strängenAn Error Occurred om ett fel inträffade. Koden iFinally – blocket rensar bara$Error – variabeln.

koden ovan, efter att ha körts i PowerShell, ger dig denna utgång som visas nedan.,

utgången ovan visar att skriptet stött på ett fel, körde koden inutiCatch blocket och avslutades sedan.

felet hanterades, vilket var felhanteringspunkten. Det visade felet var dock för generiskt. För att visa ett mer beskrivande fel kan du komma åt egenskapen Exception för felet som passerade Try.,

koden nedan ändras, specifikt koden inutiCatch – blocket, för att visa undantagsmeddelandet från det aktuella felet som skickades ner i rörledningen- $PSItem.Exception.Message

den här gången, när den ändrade koden ovan körs, visas meddelandet mycket mer beskrivande.,

fånga specifika fel

det finns tillfällen då en catch-all felhantering inte är den lämpligaste metoden. Kanske vill du att ditt skript ska utföra en åtgärd som är beroende av vilken typ av fel som uppstår.

hur bestämmer du feltypen? Genom att kontrollera egenskapenTypeName för egenskapenException för det senaste felet., Till exempel, för att hitta feltypen från föregående exempel, använd det här kommandot:

$Error.Exception | Get-Member

resultatet av koden ovan skulle se ut som skärmdumpen nedan. Som du kan se visas värdet TypeName – System.Management.Automation.ItemNotFoundException.

nu när du vet feltypen som du behöver avlyssna, ändra koden för att fånga den specifikt., Som du ser från den modifierade koden nedan finns det nu två Catch block. Den första Catch blocket fångar en viss typ av fel (System.Management.Automation.ItemNotFoundException). Däremot innehåller det andraCatch-blocket det generiska, catch-all-felmeddelandet.

skärmbilden nedan visar utmatningen av den ändrade koden ovan.,

slutsats

i den här artikeln har du lärt dig om fel i PowerShell, dess egenskaper och hur du kan bestämma ett Fels specifika typ. Du har också lärt dig skillnaden mellan parametern$ErrorActionPreference och parameternErrorAction påverkar hur PowerShell behandlar icke-avslutande fel.,

Du har också lärt dig hur du använder PowerShell Try Catch Finally block för att utföra felhantering, oavsett om det gäller specifika fel eller en catch-all-strategi.

exemplen som visas i den här artikeln visar bara grunderna för hurTry Catch Finally block fungerar. Den kunskap som jag hoppas att du har fått i den här artikeln bör ge dig startblocken för att börja tillämpa felhantering i dina skript.,

Ytterligare läsning

• About_Try_Catch_Finally
• About_Automatic_Variables
• tillbaka till grunderna: PowerShell Foreach Loop
• tillbaka till grunderna: förstå PowerShell objekt