-
Understanding the Citrix Virtual Apps and Desktops Administration Model
-
-
-
-
-
about_Broker_ErrorHandling
-
-
-
-
-
-
-
-
-
-
-
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
about_Broker_ErrorHandling
Topic
Citrix Broker SDK - Error Handling
Short Description
Describes broker errors generated by cmdlets and how to access them.
Long Description
The broker SDK cmdlets report errors through the class SdkErrorRecord, which is a subclass of the standard Powershell error record class System.Management.Automation.ErrorRecord. SdkErrorRecord contains:
-
A short string to describe the error status code. This is implemented as a public property named Status.
-
A dictionary of key-value pairs containing additional data specific to the cmdlet. This is implemented as a public property named ErrorData of type Dictionary<string, string>.
The error status property always has a value. Populating the error data dictionary is optional. The number of entries within the dictionary, the content of the entries, and the exact format of the key and value data is specific to each cmdlet.
You can access an SdkErrorRecord object using the standard Powershell cmdlet ErrorVariable parameter. The type of object returned by ErrorVariable depends on whether the error is terminating or non-terminating.
Non-Terminating Errors
For non-terminating errors, each object in the returned ErrorVariable array is simply an instance of type SdkErrorRecord.
Terminating Errors
For terminating errors, the object returned by ErrorVariable is of type System.Management.Automation.CmdletInvocationException.
For non-terminating errors that are escalated as terminating errors (through the “ErrorAction stop” argument), the object returned by ErrorVariable is of type System.Management.Automation.ActionPreferenceStopException.
CmdletInvocationException and ActionPreferenceStopException are subclasses of the base class System.Management.Automation.RuntimeException, which exposes the SdkErrorRecord object through its ErrorData property.
Class SdkOperationException
SdkErrorRecord’s Exception property holds an instance of custom exception class SdkOperationException, which also contains the error status code and data dictionary from SdkErrorRecord.
The SDK cmdlets generate errors in response to exceptions generated by the underlying system or by the cmdlet detecting errors locally and instantiating appropriate exception types. Such exceptions, which represent the original cause of the terminating error, are specified in SdkOperationException’s InnerException property.
For terminating errors, use Powershell scripts to trap SdkOperationException and access additional error information and the originating exception.
Review Of Powershell Error Handling Behavior
Powershell scripts can access error information using the following methods:
-
Read error records from the $error arraylist.
-
Get the cmdlet to return error records using the standard ErrorVariable cmdlet parameter.
-
Use trap blocks to catch exceptions for terminating errors.
The type of the error record that Powershell puts in the $error arraylist and returns through the ErrorVariable cmdlet parameter depends on whether the error is terminating or non-terminating, and whether the “ErrorAction continue” or “ErrorAction stop” cmdlet parameters are specified (that turn terminating errors into non-terminating ones, and vice versa).
For the combinations of error types (terminating, non-terminating) and error actions (stop, continue), the following statements describe the relationship between:
-
The type of object contained in the Powershell $error arraylist.
-
The type of object returned by the ErrorVariable cmdlet parameter (assuming the script can continue after a terminating error).
-
The type of the exception that is thrown (where applicable).
Non-terminating errors with ErrorAction=Continue, $error type=SdkErrorRecord, and ErrorVariable type=SdkErrorRecord do not throw an exception.
Terminating errors with ErrorAction=Stop, $error type=ErrorRecord, and ErrorVariable type=CmdletInvocationException throw an SdkOperationException exception.
Non-terminating errors with ErrorAction=Stop, $error type=ErrorRecord, and ErrorVariable type=ActionPreferenceOperationException do not throw an exception.
Terminating errors with ErrorAction=Continue, $error type=ErrorRecord, and ErrorVariable type= CmdletInvocationException throw an SdkOperationException exception.
ActionPreferenceOperationException and CmdletInvocationException are subclasses of System.Management.Automation.RuntimeException.
Accessing Error Record Data
The Powershell code sample below demonstrates how to access error information programmatically with the ErrorVariable cmdlet parameter and a trap block.
# Trap exceptions generated from terminating errors
trap [Exception] {
write ""
write "TRAP BLOCK : BEGIN”
if($_.Exception.GetType().Name -eq "SdkOperationException")
{
$sdkOpEx = $_.Exception
# show error status
write $("SdkOperationException.Status = " + $sdkOpEx.Status)
# show error data dictionary
write $("SdkOperationException.ErrorData=")
write $("SdkOperationException.InnerException = " + $sdkOpEx.InnerException)
$_.Exception.ErrorData
}
continue #could also call break here to halt script execution
write "TRAP BLOCK : END"
}
<!--NeedCopy-->
## Run tests 1 to 4, below, in turn to examine terminating and
## non-terminating error behavior.
<!--NeedCopy-->
# Test 1: Invoke cmdlet that generates a terminating error:
# New-BrokerCatalog throws terminating error if a
# catalog with the supplied name already exists.
#New-BrokerCatalog -Name "AlreadyExists" -AllocationType Random -ProvisioningType Manual -SessionSupport SingleSession -PersistUserChanges OnLocal -MachinesArePhysical $true -ErrorVariable ev
<!--NeedCopy-->
# Test 2: Force script execution to continue after a terminating error.
#New-BrokerCatalog -Name "AlreadyExists" -AllocationType Random -ProvisioningType Manual -SessionSupport SingleSession -PersistUserChanges OnLocal -MachinesArePhysical $true -ErrorVariable ev -ErrorAction continue
<!--NeedCopy-->
# Test 3: Invoke cmdlet that generates a non-terminating error:
# Get-BrokerCatalog generates a non-terminating error if a catalog
# with the specified name doesn't exist.
#Get-BrokerCatalog -Name "IDontExist" -ErrorVariable ev
<!--NeedCopy-->
# Test 4 – Force script execution to halt after a non-terminating error.
#Get-BrokerCatalog -Name "IDontExist" -ErrorVariable ev -ErrorAction "stop"
write ""
write "GET ERROR INFORAMTION: BEGIN"
$sdkErrRecord = $null
if($ev[0].GetType().Name -eq "SdkErrorRecord")
{
$sdkErrRecord = $ev[0]
}
elseif($ev[0].GetType().BaseType.FullName -eq "System.Management.Automation.RuntimeException")
{
$sdkErrRecord = $ev[0].ErrorRecord
}
else
{
write ("UNKNOWN ERROR VARIABLE TYPE:")
$ev[0].GetType().Name
}
if($sdkErrRecord -ne $null)
{
write ("Have sdkErrRecord:")
write (" Type Name = " + $sdkErrRecord.GetType().FullName)
write (" Status = " + $sdkErrRecord.Status)
write (" Exception type = " + $sdkErrRecord.Exception.GetType().FullName)
write (" ErrorData = ")
$sdkErrRecord.ErrorData
write (" FullyQualifiedErrorId = " + $sdkErrRecord.FullyQualifiedErrorId)
}
write "GET ERROR INFORAMTION: END"
<!--NeedCopy-->
Share
Share
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.