Exploring the error view and Get-Error
Since the very beginning, Windows PowerShell has done a great job in displaying the results of errors: a big blob of red text on a black background that contains full details about what went wrong. It was tremendous, but many new users found it a bit off-putting – there was too much information, some of which was not very useful in most cases.
PowerShell 7 now offers a more concise view of errors that reduces the amount of text and improves the format of the output. The result is shorter and more readable output. And, on those rare occasions when it might be necessary, you can Get-Error to get complete error details without having to parse through $Error[0].
Getting ready
You run this recipe on SRV1 after you have installed PowerShell 7 and/or Visual Studio Code, and once you have created a console profile file.
How to do it...
- Creating a simple script
$SCRIPT = @' # divide by zero 42/0 '@ $SCRIPTFILENAME = 'C:\Foo\ZeroDivError.ps1' $SCRIPT | Out-File -Path $SCRIPTFILENAME - Running the script and seeing the default error view
& $SCRIPTFILENAME - Running the same line from the console
42/0 - Viewing the
$ErrorViewvariable$ErrorView - Viewing the potential values of
$ErrorView$Type = $ErrorView.GetType().FullName [System.Enum]::GetNames($Type) - Setting
$ErrorViewto'NormalView'and recreating the error$ErrorView = 'NormalView' & $SCRIPTFILENAME - Setting
$ErrorViewto'CategoryView'and recreating the error$ErrorView = 'CategoryView' & $SCRIPTFILENAME - Setting
$ErrorViewto its default value$ErrorView = 'ConciseView'
How it works...
In step 1, you create a script that contains a (deliberate) divide-by-zero error. This step creates the file, but creates no other output.
In step 2, you run the script from within VS Code, and view the resulting error, which looks like this:
Figure 2.43: Running the script and viewing the error
In step 3, you create a divide-by-zero error from the command line. The output from this step looks like this:
Figure 2.44: Running the same line from the console
PowerShell 7 uses the built-in $ErrorView variable to hold the name of the error view PowerShell should use to display errors. In step 4, you view the current value of this variable, which looks like this:
Figure 2.45: Viewing the value of the $ErrorView variable
The $ErrorView variable can take one of three values, as you can see from the output of step 5:
Figure 2.46: Viewing the potential values of $ErrorView
In step 6, you set the value of $ErrorView to display the error using the output generated by Windows PowerShell and then re-view the error, which looks like this:
Figure 2.47: Setting $ErrorView to NormalView and recreating the error
In step 7, you set $ErrorView to display the error using CategoryView and then recreate the error. The output from this step shows the category error view:
Figure 2.48: Setting $ErrorView to CategoryView and recreating the error
In step 8, you reset the value of $ErrorView to the default value. This step creates no output.
There's more...
The concise error view you see in the output from step 2 contains all the information from the standard view that you can see in the output from step 7, except for the omission of the error category information. And if you invoke the error directly from the command line, as shown in step 3, you see only the error message, which is easier on the eyes.
In step 5, you view the error category information. In most cases, this is not particularly useful.
In step 8, you reset the value of $ErrorView. Depending on what you are doing, this step may not be needed. You can just exit the PowerShell console (or VS Code), and the next time you start PowerShell, it resets the value back to the default (ConciseView). And if you should prefer the normal or category error views, you can always set a value to $ErrorView in your profile file.
Although not shown in this recipe, you can use the Get-Error cmdlet to show you complete error information about a specific error. For most IT Professionals, the basic error information provided by PowerShell 7 is more than adequate (and a great improvement over error output with Windows PowerShell).
