POWERSHELL - ERROR HANDLING - NON TERMINATING ERRORS

Siamo arrivati all'appuntamento conclusivo del ciclo di articoli dedicati alle strategie di gestione degli errori in PowerShell. Come ultimo tema trattiamo i Non-Terminating Errors, una tipologia di errori particolari con caratteristiche e strategie differenti dalle normali Exception.

Fonte: Powershell troubleshooting guide

di Michael Shepard

ISBN 978-1-78217-357-1

Non-Terminating Errors

I "non-terminating errors" sono una tipologia di errore particolare e appartengono alla categoria dei linguaggi di scripting come PowerShell. A differenza delle Exception, che interrompono l'esecuzione del codice in un determinato punto, questi errori invece non lo fanno, andando a scrivere dei messaggi di errore in un buffer parallelo e evitando l'esecuzione del blocco catch. Immaginiamo i non-terminating errors come delle operazioni asincrone, la cui esecuzione deve essere analizzata a posteriori, vanificando la possibilità di intercettare l'errore utilizzando blocchi try-catch o trap.

Per fare un esempio, immaginiamo di avere due cartelle: "folderOne" e "folderThree" con dei file all'interno, notiamo che manca all'appello "folderTwo". Tramite il cmdlet DIR vengono elencati i file e cartelle contenuti nel path di input, volendo è possibile specificare più di un path per ottenere in sequenza tutti i contenuti. 

dir .\folderOne, .\folderTwo, .\folderThree

Esempio: non-terminating error

Come possiamo vedere dalla immagine, quando il cmdlet DIR ha incontrato la folder non essitente "folderTwo" non ha terminato l'esecuzione, semplicemente è stato aggiunto un testo allo stream di errore ed è stato visualizzato, senza interrompere l'esecuzione.

Parametro -ErrorAction

I cmdlet offrono il parametro -ErrorAction per specificare a PowerShell come comportarsi a fronte di un problema. Prendendo l'esempio precedente, aggiungendo il parametro -ErrorAction con il valore SilentlyContinue, l'errore non sarà aggiunto allo stream di error:

Esempio: non-terminating error con silently continue

Dove è andato a finire l'errore generato? il sistema aggiunge alla variaible interna $Error tutte gli errori silenziati tramite il parametro -ErrorAction SilentlyContinue.

Sono possibili i seguenti parametri di -ErrorAction:

Valore	Descrizione
Stop	Gestisce l'errore come una Exception, quindi termina l'esecuzione se non all'interno di un blocco try-catch
Continue	Viene mostrato l'errore a schermo ma l'esecuzione viene ripresa dalla istruzione successiva. L'errore viene aggiunto a $Error
SilentlyContinue	Viene ripresa l'istruzione successiva senza mostrare un messaggio a schermo. L'errore viene aggiunto a $Error
Inquire	Viene chiesto all'utente se proseguire o meno
Ignore	Viene ignorato l'errore, non viene visualizzato e non viene aggiunto a $Error

Implementare -ErrorAction in una funzione personalizzata

Durante il nostro tutorial introduttivo di PowerShell, non era mai stata trattata la differenza fondamentale fra un cmdlet di sistema e uno personalizzato (function), ma di base i cmdlet di sistema condividono un set di parametri standard sempre accessibili a prescindere dal cmdlet utilizzato, come infatti -ErrorAction.

Per farsì che anche un cmdlet personalizzato risponda ai parametri standard dei cmdlet di sistema, è necessario aggiungere delle keywords al codice della funzione:

function division{
[CmdletBinding()]
Param($a,$b)
return $a/$b
}

Esempio: cmdlet personalizzata con gestione di -ErrorAction

Così facendo abbiamo realizzato una funzione in grado di rispondere al parametro -ErrorAction proprio come i cmdlet di sistema. Attenzione: l'utilizzo di CmdletBinding() presuppone l'eredità di tutti i parametri comuni dei cmdlet non solo -ErrorAction (ad esempio: -Verbose o -Debug).

Conclusione

PRO	CONTRO
Uniforma l'utilizzo dei cmdlet di sistema a quelli personalizzati. Permette di gestire gli errori praticamente non scrivendo nulla nel codice, lasciando il codice pulito e semplice.	Chi non è abituato ad usare i cmdlet di sistema non conosce il parametro -ErrorAction. Non lascia la stessa libertà di gestione dell'errore che si ha con un blocco try-catch-finally.