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:
write-host -BackGroundColor Green "UnTrapped Exception...."
write-host "Type: " $_.GetType().FullName
write-host "Exception: " $_.Exception
which outputs this:
Netapp UnTrapped Exception....
Exception: NetApp.Ontapi.ErrnoException+EVOLUMEDOESNOTEXIST: No volume named 'CWSQLSnapInfX' exists
at NetApp.Ontapi.NaApi`1.Invoke(INaServer server)
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.
I had a similar issue when I started using try/catch. For the try/catch code to work, PowerShell must know to stop when an error occurs. This "stop" invokes the try/catch process. If the exception is handled, the script will handle the error and continue running the script. There are two (2) ready methods for doing telling PowerShell to stop on errors..
1. Add -ErrorAction Stop to the cmdlet whose error you are trying to catch.