Unable to catch DriveNotFoundException from Get-PSDrive - powershell

Question

I'm unable to catch the DriveNotFoundException being generated by Get-PSDrive in the following example:
try {
# Assumes no Q:\ drive connected.
$foo = Get-PSDrive -name 'Q' -ErrorAction Stop
}
catch [System.Management.Automation.DriveNotFoundException] {
Write-Output "Drive not found."
}
catch {
Write-Output "Something else went wrong."
}
This should print the following:
PS C:\temp> .\foo.ps1
Drive not found.
PS C:\temp>
Instead, I get:
PS C:\temp> .\foo.ps1
Something else went wrong.
PS C:\temp>
I'm using Powershell 2.0, if that's relevant.

Answer 1

The issue is because the -ErrorAction Stop is changing the Exception type that the try/catch block is seeing.
You can prove it by catching the ActionPreferenceStopException type. So let's run some troubleshooting code to see what is going on:
try {
# Assumes no Q:\ drive connected.
$foo = Get-PSDrive -name 'Q' -ErrorAction Stop
}
catch [System.Management.Automation.DriveNotFoundException] {
Write-Output "Drive not found."
}
catch [System.Management.Automation.ActionPreferenceStopException] {
Write-Output "Stop Exception."
write-host "Caught an exception:" -ForegroundColor Red
write-host "Exception Type: $($_.Exception.GetType().FullName)" -ForegroundColor Red
write-host "Exception Message: $($_.Exception.Message)" -ForegroundColor Red
}
catch
{
write-host "Caught an exception:" -ForegroundColor Red
write-host "Exception Type: $($_.Exception.GetType().FullName)" -ForegroundColor Red
write-host "Exception Message: $($_.Exception.Message)" -ForegroundColor Red
}
This returns the following output:
Stop Exception.
Caught an exception:
Exception Type: System.Management.Automation.DriveNotFoundException
Exception Message: Cannot find drive. A drive with the name 'Q' does not exist.
So you see that the try/catch caught the [System.Management.Automation.ActionPreferenceStopException] exception, Even Though the Exception type is [System.Management.Automation.DriveNotFoundException] inside the catch block.
So, we can handle it with a slightly modified version of #haliphax's solution, which is to check the error type inside the ActionPreferenceStopException catch block:
try {
# Assumes no Q:\ drive connected.
$foo = Get-PSDrive -name 'Q' -ErrorAction Stop
}
catch [System.Management.Automation.ActionPreferenceStopException] {
if ($Error[0].Exception.GetType().Name -eq 'DriveNotFoundException') {
Write-Output "Drive not found."
}
else {
Write-Output "Something else went wrong."
}
}
catch {
Write-Output "Something else went wrong."
}

Answer 2

To complement HAL9256's great answer:
Note: The following is in part speculative. Do let me know if I'm wrong.
The behavior observed is a presumably a bug in PowerShell v1 and v2 , where the internal exception of type [System.Management.Automation.ActionPreferenceStopException] accidentally masks the original exception in the matching logic of typed catch blocks in a try / catch statement.
The reason I suspect that [System.Management.Automation.ActionPreferenceStopException] is purely an internal exception that should never have been exposed, is that both $Error[0].Exception and its alias inside a catch block, $_.Exception, reflect the original exception, even in PowerShell v1 and v2 - the $Errors collection contains no trace of [System.Management.Automation.ActionPreferenceStopException].
While the bug is fixed in v3+, v3+ still, but now also matches [System.Management.Automation.ActionPreferenceStopException] in typed catch handlers, presumably so as not to break backward compatibility.
There is little benefit in catching [System.Management.Automation.ActionPreferenceStopException], given its generic nature (it just tells you that a cmdlet experienced a non-terminating error).
The only conceivable reason for catching it is if you wanted to know whether the exception at hand was natively terminating or only treated as terminating due to -ErrorAction Stop or $ErrorActionPreference = 'Stop'.
Thus, for code that must also on run v2-, I'd solve the problem as follows:
try {
# Assumes no Q:\ drive connected.
$foo = Get-PSDrive -name 'Q' -ErrorAction Stop
}
catch { # Use a generic handler to work around the bug in v1 an v2.
# $_ is the [System.Management.Automation.ErrorRecord] instance representing
# the PowerShell error at hand (same as $Error[0]).
# $_.Exception contains the exception that triggered the error,
# and can be compared to specific exception types with -is.
if ($_.Exception -is [System.Management.Automation.DriveNotFoundException]) {
"Drive not found."
} else {
"Something else went wrong."
}
}

Answer 3

I realize that this is due to some strange behavior (according to the above comments about later versions of PowerShell), but this does manage to handle the specific error:
try {
$foo = Get-PSDrive -name 'Q' -ErrorAction Stop
}
catch {
if ($Error[0].Exception.GetType().Name -eq 'DriveNotFoundException') {
Write-Output 'No such drive.'
}
else {
Write-Output 'Something else went wrong.'
}
}

Answer 4

This is just a brief post of the final version of the code I used, based on the explanation provided by #HAL9256 in his answer:
try {
# Assumes no Q:\ drive connected.
$foo = Get-PSDrive -name 'Q' -ErrorAction Stop
}
# Catch exceptions thrown by both v2.0 and by later versions.
catch [System.Management.Automation.ActionPreferenceStopException], `
[System.Management.Automation.DriveNotFoundException] {
Write-Output "Drive not found."
}
catch {
Write-Output "Something else went wrong."
}
This has been tested on both PowerShell 2.0 & 4.0 and works on both. I suppose there's a minor risk that some other exception will occur in the Get-PSDrive statement in a PowerShell 2.0 environment, triggering the catch block, but in my use case, it's an acceptable risk and will trigger a different exception later in the script.