Try/catch ne semble pas avoir un effet

Je suis nouveau sur powershell, et je suis en train d'ajouter la gestion des erreurs via les instructions try/catch, mais ils ne semblent pas être réellement la capture de l'erreur. C'est powershell v2 CP3.

$objComputer = $objResult.Properties;
$strComputerName = $objComputer.name
write-host "Checking machine: " $strComputerName

try
{
    $colItems = get-wmiobject -class "Win32_PhysicalMemory" -namespace "root\CIMV2" -computername $strComputerName -Credential $credentials
    foreach ($objItem in $colItems) 
    {
        write-host "Bank Label: " $objItem.BankLabel
        write-host "Capacity: " ($objItem.Capacity / 1024 / 1024)
        write-host "Caption: " $objItem.Caption
        write-host "Creation Class Name: " $objItem.CreationClassName      
        write-host
    }
}
Catch 
{
    write-host "Failed to get data from machine (Error:"  $_.Exception.Message ")"
    write-host
}
finally 
{ }

Quand il ne parvient pas à communiquer avec une machine spécifique, j'obtiens ceci dans la console, et non de ma propre attraper message:

Get-WmiObject : The RPC server is unavailable. (Exception from HRESULT: 0x800706BA) At Z:\7.0 Intern Programvare\Powershell\Get memory of all computers in AD.ps1:25 char:34 + $colItems = get-wmiobject <<<< -class "Win32_PhysicalMemory" -namespace "root\CIMV2" -computername $strComputerName -Credential $credentials + CategoryInfo : InvalidOperation: (:) [Get-WmiObject], COMException + FullyQualifiedErrorId : GetWMICOMException,Microsoft.PowerShell.Commands.GetWmiObjectCommand

InformationsquelleAutor EKS | 2009-07-17

powershell

J'ai été en mesure de reproduire votre résultat lorsque vous essayez d'exécuter une requête WMI à distance. L'exception n'est pas interceptée par le Try/Catch, ni un Piège, l'attraper, car il n'est pas une "terminaison d'erreur". Dans PowerShell, il y a de terminaison d'erreurs et de non-terminaison des erreurs . Il semble que les Try/Catch/finally et le Piège ne fonctionne qu'à la fin des erreurs.

Il est connecté à l' $erreur variable automatique et vous pouvez tester ce type de non-terminaison des erreurs en regardant le $? variable automatique, ce qui vous permettra de savoir si la dernière opération a réussi ($true) ou d'échec ($false).

À partir de l'apparition de l'erreur générée, il semble que l'erreur est retourné et non enveloppé dans un catchable exception. Ci-dessous est une trace de l'erreur générée.

PS C:\scripts\PowerShell> Trace-Command -Name errorrecord  -Expression {Get-WmiObject win32_bios -ComputerName HostThatIsNotThere}  -PSHost
DEBUG: InternalCommand Information: 0 :  Constructor Enter Ctor
Microsoft.PowerShell.Commands.GetWmiObjectCommand: 25857563
DEBUG: InternalCommand Information: 0 :  Constructor Leave Ctor
Microsoft.PowerShell.Commands.GetWmiObjectCommand: 25857563
DEBUG: ErrorRecord Information: 0 :  Constructor Enter Ctor
System.Management.Automation.ErrorRecord: 19621801 exception =
System.Runtime.InteropServices.COMException (0x800706BA): The RPC
server is unavailable. (Exception from HRESULT: 0x800706BA)
   at
System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
   at System.Management.ManagementScope.InitializeGuts(Object o)
   at System.Management.ManagementScope.Initialize()
   at System.Management.ManagementObjectSearcher.Initialize()
   at System.Management.ManagementObjectSearcher.Get()
   at Microsoft.PowerShell.Commands.GetWmiObjectCommand.BeginProcessing()
errorId = GetWMICOMException errorCategory = InvalidOperation
targetObject =
DEBUG: ErrorRecord Information: 0 :  Constructor Leave Ctor
System.Management.Automation.ErrorRecord: 19621801

Un travail autour de votre code pourrait être:

try
{
    $colItems = get-wmiobject -class "Win32_PhysicalMemory" -namespace "root\CIMV2" -computername $strComputerName -Credential $credentials
    if ($?)
    {
      foreach ($objItem in $colItems) 
      {
          write-host "Bank Label: " $objItem.BankLabel
          write-host "Capacity: " ($objItem.Capacity / 1024 / 1024)
          write-host "Caption: " $objItem.Caption
          write-host "Creation Class Name: " $objItem.CreationClassName      
          write-host
      }
    }
    else
    {
       throw $error[0].Exception
    }

Mis à jour avec une solution de contournement.
Vous pouvez faire de la non-terminaison erreurs jeté à l'aide de: -ErrorAction "Stop" (ou -ÉE "Stop" pour faire court)
Vous avez raison! Paramètre $ErrorActionPreference de 'Stop' marcherait aussi bien, mais aurait un effet global.
Murawski - sauf si vous enlevez dans le bloc finally.
vous ne savez pas si cela va fonctionner avec un .net appel de méthode qui déclenche une exception
.NET des exceptions sont toujours de la résiliation, de sorte qu'ils peuvent être pris sans effort supplémentaire.
N'oubliez pas de vider la collection des erreurs avant l'exécution de la ligne critique. $error.Clear()
Je ne sais pas pourquoi des gens comme $Error[0] tellement. Si vous utilisez $_ dans un catch vous éviter d'avoir à effacer le message d'erreur de cache et le risque de déclarer une erreur s'est produite dans la capture elle-même.

InformationsquelleAutor Steven Murawski

Si vous voulez try/catch de travail pour toutes les erreurs (et pas seulement la résiliation des erreurs), vous pouvez effectuer manuellement toutes les erreurs de résiliation par le réglage de la ErrorActionPreference.

try {

   $ErrorActionPreference = "Stop"; #Make all errors terminating
   get-item filethatdoesntexist; # normally non-terminating
   write-host "You won't hit me";  
} catch{
   Write-Host "Caught the exception";
   Write-Host $Error[0].Exception;
}finally{
   $ErrorActionPreference = "Continue"; #Reset the error action pref to default
}

Sinon... vous pouvez faire votre propre trycatch fonction qui accepte scriptblocks de sorte que votre essayez d'attraper les appels ne sont pas comme quelque chose. J'ai la mienne retourner true/false juste au cas où j'ai besoin de vérifier si il y avait une erreur... mais il ne marche pas avoir à le faire. Aussi, enregistrement d'exception est optionnel et peut être pris en charge dans le catch, mais je me suis toujours à l'appel de la fonction d'enregistrement dans le bloc catch, donc je l'ai ajouté à la try catch fonction.

function log([System.String] $text){write-host $text;}

function logException{
    log "Logging current exception.";
    log $Error[0].Exception;
}


function mytrycatch ([System.Management.Automation.ScriptBlock] $try,
                    [System.Management.Automation.ScriptBlock] $catch,
                    [System.Management.Automation.ScriptBlock]  $finally = $({})){



# Make all errors terminating exceptions.
    $ErrorActionPreference = "Stop";

    # Set the trap
    trap [System.Exception]{
        # Log the exception.
        logException;

        # Execute the catch statement
        & $catch;

        # Execute the finally statement
        & $finally

        # There was an exception, return false
        return $false;
    }

    # Execute the scriptblock
    & $try;

    # Execute the finally statement
    & $finally

    # The following statement was hit.. so there were no errors with the scriptblock
    return $true;
}


#execute your own try catch
mytrycatch {
        gi filethatdoesnotexist; #normally non-terminating
        write-host "You won't hit me."
    } {
        Write-Host "Caught the exception";
    }

Essayez d'utiliser " ::Essayez de diviser par zéro: $(0/0)" (et ne pas utiliser get-item filethatdoesntexist;). Alors qu'il ne l'attrape pas cette exception

InformationsquelleAutor Jon Donnelly

Il est également possible de définir l'erreur de l'action de préférence individuelle des applets de commande, et pas seulement pour l'ensemble du script. Ceci est fait en utilisant le paramètre-ErrorAction (alisa EA), qui est disponible sur toutes les applets de commande.

Exemple

try 
{
 Write-Host $ErrorActionPreference; #Check setting for ErrorAction - the default is normally Continue
 get-item filethatdoesntexist; # Normally generates non-terminating exception so not caught
 write-host "You will hit me as exception from line above is non-terminating";  
 get-item filethatdoesntexist -ErrorAction Stop; #Now ErrorAction parameter with value Stop causes exception to be caught 
 write-host "you won't reach me as exception is now caught";
}
catch
{
 Write-Host "Caught the exception";
 Write-Host $Error[0].Exception;
}

InformationsquelleAutor Alastair Bell

7

C'est ma solution. Lors de la Set-location échoue il jette à un non-terminaison d'erreur qui n'est pas vu par le bloc catch. L'ajout d'-ErrorAction Arrêt de la façon la plus simple de contourner cette.
```
try {
    Set-Location "$YourPath" -ErrorAction Stop;
} catch {
    Write-Host "Exception has been caught";
}
```
InformationsquelleAutor Mike Seeds
3

Ajoutant "-EA Arrêter" résolu pour moi.

InformationsquelleAutor Brian
1

Edit: Comme indiqué dans les commentaires, la solution suivante s'applique à PowerShell V1 uniquement.

Voir ce blog sur les Techniques", les Aventures d'Adam Weigert" pour plus de détails sur la façon de le mettre en œuvre.

Exemple d'utilisation (copier/coller à partir d'Adam Weigert blog):
```
Try {
    echo " ::Do some work..."
    echo " ::Try divide by zero: $(0/0)"
} -Catch {
    echo "  ::Cannot handle the error (will rethrow): $_"
    #throw $_
} -Finally {
    echo " ::Cleanup resources..."
}
```
Sinon, vous devrez utiliser d'interception des exceptions.
- blogs.msdn.com/powershell/archive/2009/06/17/... Pr ce faire, elle doit exister dans la V2 .
- Try/Catch/finally n'existe pas dans la V1 de PowerShell, mais il est en V2.
- Ah, bien sûr, mon erreur.
- tout bon exemple de gestion d'erreur à l'aide de la V2 ?
InformationsquelleAutor bernhof

Dans mon cas, c'était parce que j'étais seulement la capture de certains types d'exceptions:

try
  {
    get-item -Force -LiteralPath $Path -ErrorAction Stop

    #if file exists
    if ($Path -like '\\*') {$fileType = 'n'}  #Network
    elseif ($Path -like '?:\*') {$fileType = 'l'} #Local
    else {$fileType = 'u'} #Unknown File Type

  }
catch [System.UnauthorizedAccessException] {$fileType = 'i'} #Inaccessible
catch [System.Management.Automation.ItemNotFoundException]{$fileType = 'x'} #Doesn't Exist

Ajoutés à la poignée supplémentaire à l'exception provoquant la résiliation de l'erreur, ainsi que les exceptions inattendues

catch [System.Management.Automation.DriveNotFoundException]{$fileType = 'x'} #Doesn't Exist
catch {$fileType='u'} #Unknown

InformationsquelleAutor squicc

Vous devez vous connecter pour publier un commentaire.