Nope, you're not doing anything silly. That's exactly how I would expect it to work too.
PowerShell is doing something silly though. First, EVOLUMEDOESNOTEXIST is a non-terminating error for this cmdlet; you have to set the ErrorAction parameter or $ErrorActionPreference variable otherwise it will just write the error and continue. When you change the ErrorAction to stop, PowerShell wraps the exception in an ErrorRecord object before throwing it down the stack. Obviously "ErrorRecord" won't match the catch type.
There are a number of ways to handle this appropriately, but matching the Exception property looks nice to me:
$ErrorActionPreference = "Stop"
$volName = "CWSQLSnapInfX"
try {
#$res = new-object NetApp.Ontapi.ApiResult
#throw new-object NetApp.Ontapi.Filer.ErrnoException+EVOLUMEDOESNOTEXIST $res
$hVol = get-naVol $volName
write-host "hVol: " + $hVol.Name
}
catch {
if ($_.Exception.GetType() -match "EVOLUMEDOESNOTEXIST")
{
write-host -BackGroundColor Yellow " Netapp UnTrapped Exception...."
write-host "Quitting...."
} else {
write-host -BackGroundColor Green "UnTrapped Exception...."
}
write-host "Type: " $_.GetType().FullName
write-host "Exception: " $_.Exception
}
which outputs this:
Netapp UnTrapped Exception....
Quitting....
Type: System.Management.Automation.ErrorRecord
Exception: NetApp.Ontapi.ErrnoException+EVOLUMEDOESNOTEXIST: No volume named 'CWSQLSnapInfX' exists
at NetApp.Ontapi.NaApi`1.Invoke(INaServer server)
at DataONTAP.PowerShell.SDK.Cmdlets.Volume.GetNaVol.ProcessRecord()
Another benefit of doing it this way is that your scripts will still run against the upcoming 1.6 Toolkit release in which the NaErrnoException types have all moved to a new namespace (just "NetApp.Ontapi").
Great question by the way... I really had to scratch my head on this one.
Regards,
Eric