Windows PowerShellIntercettazione degli errori

Don Jones

Contenuto

L'impostazione di una trap
Interrompi.
È tutto in dell'ambito
Interruzione fuori
Perché preoccuparsi?

Video

Continuare la discussione sulla creazione di un potente strumento inventorying in Windows PowerShell, Don Jones attiva sua attenzione intercettazione degli errori.In relativo video questo mese, Don viene illustrato come è possibile incorporare gestione degli errori le funzioni di base di Windows PowerShell.

Nella dispensa precedente di questo articolo, mostrato come creare uno strumento piuttosto avanzata del magazzino utilizzando Windows PowerShell.Lo strumento creato offerte varie opzioni sull'output, grazie alle funzionalità incorporate della shell e l'utilizzo della funzione di oggetti.

Un aspetto in verità debole della funzione che è stata creata è che Impossibile affrontare correttamente gli eventuali errori potrebbero, ad esempio problemi di connettività o autorizzazioni.Ovvero ciò che voglio indirizzo nella dispensa di questo mese della colonna di Windows PowerShell, desiderato alle funzionalità di gestione degli errori offerte da Windows PowerShell.

L'impostazione di una trap

La parola chiave trap in Windows PowerShell definisce un gestore degli errori.Quando si verifica un'eccezione nello script, la shell aspetto per verificare se una registrazione è stata definita, questo significa che la registrazione deve essere inserita nello script prima di eventuali eccezioni.Per questa dimostrazione, verrà realizzare uno script di test che è possibile sapere genererà un problema di connettività: get-WmiObject verrà utilizzato per connettersi a un nome computer che è possibile sapere non esiste sulla rete.Lo scopo consiste nel richiedere la trap errore scrive il nome computer non valido in un file, assegnazione di un file di nomi di computer che non funzionano.Saranno includere anche le connessioni ai due computer che sono accessibili (È necessario utilizzare localhost).È possibile visualizzare lo script in figura 1 .

Figura 1 aggiunta la registrazione dei colori

trap {
  write-host "Error connecting to $computer" -fore red
  "$computer" | out-file c:\demo\errors.txt -append 
  continue
}

$computer = "localhost"
get-wmiobject win32_operatingsystem -comp $computer 

$computer = "server2"
get-wmiobject win32_operatingsystem -comp $computer 

$computer = "localhost"
get-wmiobject win32_operatingsystem -comp $computer

L'output da questo script illustrato nella Figura 2 è non è esattamente ciò che ricercata. Si noti che il messaggio "Errore di connessione to…" non visualizzata. Il file Errors.txt non è stato creato uno. In altre parole, la trap non eseguire affatto. Dov ' è?

Nella figura 2 questo non è l'output È stato sperando per!

Interrompi.

La chiave è per comprendere che un messaggio di errore normale shell non equivale a un'eccezione. (Sono presenti errori non terminato ed errori di terminazione. Errori di terminazione interrompere l'esecuzione del pipeline e risultato un'eccezione.) Solo le eccezioni possono essere bloccate. Quando si verifica un errore, la shell esaminato la variabile ErrorActionPreference $ incorporata per vedere cosa è necessario fare. Per impostazione predefinita tale variabile utilizzato con il valore continua, ovvero "visualizzare un messaggio di errore e mantenere verrà". Modifica di questa variabile a "Interrompi" provoca per visualizzare un messaggio di errore e generare un'eccezione intercettabile. Tuttavia, pertanto che qualsiasi errore nello script tale scopo.

Una tecnica migliore consiste nel richiedere solo il cmdlet si ritiene che il comportamento di "Termina potrebbe causare un utilizzo del problema. È possibile eseguire utilizzando il parametro –ErrorAction (o –EA), un parametro comune supportato da tutti i cmdlet. La versione rivista dello script è illustrata nella Figura 3 . Funziona come previsto, produrre l'output è disponibile nella Figura 4 .

Nella Figura 3 Utilizzo - ErrorAction

trap {
  write-host "Error connecting to $computer" -fore red
    "$computer" | out-file c:\demo\errors.txt -append 
  continue
}

$computer = "localhost"
get-wmiobject win32_operatingsystem -comp $computer -ea stop

$computer = "server2"
get-wmiobject win32_operatingsystem  -comp $computer -ea stop

$computer = "localhost"
get-wmiobject win32_operatingsystem  -comp $computer -ea stop

Nella figura 4 è possibile ottenere risultati più utili quando si utilizza il parametro –ErrorAction

L'utilizzo di continua alla fine della trap indica la shell di riprendere l'esecuzione dalla riga di codice di quella che ha prodotto l'eccezione. L'altra opzione consiste di utilizzare la parola chiave interruzione (tratterò che in un momento). Si noti inoltre che la variabile $ computer, che è definita in script, è ancora valida all'interno la registrazione. Significa che la registrazione è un ambito figlio dello script, ovvero la registrazione è possibile visualizzare tutte le variabili all'interno dello script (ulteriori informazioni al riguardo in un momento troppo).

È tutto in dell'ambito

Un aspetto particolarmente difficile di intercettazione degli errori in Windows PowerShell è l'utilizzo dell'ambito. La shell stesso rappresenta l'ambito globale, che contiene tutto ciò che consente di passare all'interno della shell. Quando si esegue uno script, ottiene il proprio ambito script. Se si definisce una funzione, all'interno della funzione è proprio ambito privata e così via. Verrà creato un ordinamento di tipo padre-figlio di gerarchia.

Quando si verifica un'eccezione, la shell cerca una registrazione nell'ambito corrente. Ciò significa che un'eccezione all'interno di una funzione cercherà una registrazione all'interno di tale funzione. Se la shell rileva una registrazione dei colori, la shell esegue la registrazione. Se la trap non termina con continua, la shell riprenderà l'esecuzione sulla riga di codice che segue quello che ha causato l'eccezione, rimanente nello stesso ambito. Ecco un po'di pseudocodice per illustrare questo concetto:

01  Trap {
02    # Log error to a file
03    Continue
04  }
05  Get-WmiObject Win32_Service –comp "Server2" –ea "Stop"
06  Get-Process

Se si verifica un'eccezione alla riga 5, verrà eseguita la registrazione nella riga 1. La trap termina con continua, in modo nella riga 6 verrà ripresa l'esecuzione.

Si consideri ora questo esempio leggermente diverso dell'ambito:

01  Trap {
02    # Log error to a file
03    Continue
04  }
05   
06  Function MyFunction {
07    Get-WmiObject Win32_Service –comp "Server2" –ea "Stop"
08    Get-Process
09  }
10   
11  MyFunction
12  Write-Host "Testing!"

Se si verifica un errore nella riga 7, la shell eseguita la ricerca per una registrazione nell'ambito della funzione. Non è uno, in modo che la shell esce da ambito della funzione e cerca una registrazione nell'ambito padre. Esiste una registrazione dei colori e quindi viene eseguito nella riga 1. La riga di codice nello stesso ambito seguito l'eccezione in questo caso, si riprenderà continua, che è la riga 12, non riga 8. In altre parole, la shell non nuovamente la funzione dopo che è terminato.

Ora contrasto tale comportamento con questo esempio:

01  Function MyFunction {
02    Trap {
03      # Log error to a file
04      Continue
05    }
06    Get-WmiObject Win32_Service –comp "Server2" –ea "Stop"
07    Get-Process
08  }
09   
10  MyFunction
11  Write-Host "Testing!"

In questo caso, l'errore nella riga 6 verrà eseguita la registrazione nella riga 2, rimanere nell'ambito della funzione. La parola chiave continua rimarranno in tale ambito riprendere l'esecuzione sulla riga 7. Tratta il vantaggio a includere una registrazione nell'ambito in cui si prevede l'errore si verifica, rimangono nell'ambito e possibile riprendere l'esecuzione in essa contenute. Ma cosa succede se questo metodo non funziona nello scenario?

Cmdlet del mese: oggetto di confronto

Questo è uno strumento interessante per la gestione di configurazione previsioni. Oggetto di confronto o il relativo differenza, di alias consente di confrontare due insiemi di oggetti a un altro. Per impostazione predefinita, confronta ogni proprietà di ogni oggetto ed eventuali differenze sono output del comando. Pertanto, si supponga che è stato utilizzato un server di servizi configurati esattamente nel modo desiderato. Eseguita per la creazione di una previsione:

Get-Service | Export-CliXML c:\baseline.xml

Quasi qualsiasi oggetto può essere reindirizzato da esportare, CliXML, che verrà disattivata gli oggetti in un file XML. Successivamente, è possibile eseguire il comando stesso, ad esempio servizio Get e confrontare i risultati che salvati XML. Ecco come:

Compare-Object (Get-Service) (Import-CliXML 
  c:\baseline.xml) –property name

Aggiungere il parametro –property impone il confronto per visualizzare solo tale proprietà, anziché l'intero oggetto. In questo caso, si verrà ottenere un elenco delle eventuali nomi di servizio sono diversi della previsione originale consentendo sapere se i servizi sono stati aggiunti o rimossi dopo la creazione della previsione.

Interruzione fuori

Versioni precedenti, detto la parola chiave di interruzione. Nella figura 5 viene illustrato un esempio di come è possibile inserire la parola chiave interruzione in azione.

Nella figura 5 tramite la parola chiave interruzione

01  Trap {
02    # Handle the error
03    Continue
04  }
05   
06  Function MyFunction {
07    Trap {
08      # Log error to a file
09      If ($condition) {
10        Continue
11      } Else {
12        Break
13      }
14    }
15    Get-WmiObject Win32_Service –comp "Server2" –ea "Stop"
16    Get-Process
17  }
18   
19  MyFunction
20  Write-Host "Testing!"

Ecco una rapida panoramica del catena di esecuzione. Riga 19 esegue prima, la chiamata alla funzione nella riga 6. Riga 15 esegue e genera un'eccezione. Tale eccezione viene intercettato nella riga 7 e quindi nella riga 9 la trap necessario apportare una decisione. Supponendo che $ condizione è True, la registrazione dei colori continuerà l'esecuzione nella riga 16.

Se, tuttavia, $ condizione è false, la registrazione verrà Interrompi. Questo termina l'ambito corrente e passa l'eccezione originale fino all'elemento padre. Dalla visualizzazione della shell, che indica la riga 19 generato un'eccezione che viene intercettato da riga 1. La parola chiave continua impone la shell per riprendere la riga 20.

In realtà, entrambe queste registrazioni avrebbe qualche altro codice in esse per gestire l'errore, accedere e così via. È stato omesso semplicemente codice funzionale in questo esempio per facilitare la visualizzare il flusso effettivo.

Perché preoccuparsi?

Quando è necessario implementare l'intercettazione degli errori? Solo quando si prevede che potrebbe verificarsi un errore e quando si desidera un comportamento diverso da un messaggio di errore comune, ad esempio registrazione l'errore in un file o visualizzare un messaggio di errore più utile.

In genere includono in script più complessi consentono di gestire gli errori che È possibile prevedano convalidino di gestione degli errori. Questi include, ma non si limitano a errori come problemi di connettività o autorizzazioni non validi.

Intercettazione degli errori in modo definito richiede un po'più sforzo tempo per comprendere. Come avanzamento in attività più complesse in Windows PowerShell, tuttavia, intercettazione degli errori saranno anche opportuno l'investimento per apportate uno strumento più elegante e professionale.

Don Jones è coautore di Windows PowerShell: TFM e autore di decine di altri libri IT. Contattarlo tramite il suo blog all' concentratedtech.com.