Microsoft Virtualization Discussions

Exception Syntax

dashamalla2
3,224 Views

I can't figure out the Exception syntax for my try/catch statement.  I am trying to catch the case of an invalid volume.  CWSLSnapInfX does not exist.   Here is the current code:

$volName = "CWSQLSnapInfX"

try  {

    $hVol = get-naVol -controller $nvController $volName

    write-host "hVol: " + $hVol.Name

}

catch [NetApp.Ontapi.Filer.ErrnoException] {

    write-host -BackGroundColor Yellow " Netapp UnTrapped Exception...."

    write-host "Quitting...."

    write-host "Type: " + $_.Exception.GetType()

    break

}

catch [Exception] {

    write-host -BackGroundColor Green "UnTrapped Exception...."

    write-host "Type: " + $_.Exception.GetType()

    write-host "Base: " + $_.Exception.GetBaseException()

    break

}

Only the catch [Exception] block gets run.  My output looks like this:

UnTrapped Exception....

Type:  + NetApp.Ontapi.Filer.ErrnoException+EVOLUMEDOESNOTEXIST

Base:  + NetApp.Ontapi.Filer.ErrnoException+EVOLUMEDOESNOTEXIST: No volume named 'CWSQLSnapInfX' exists

   at NetApp.Ontapi.NaApi`1.Invoke(INaServer server)

   at DataONTAP.PowerShell.SDK.Cmdlets.Volume.GetNaVol.ProcessRecord()

Error[0]:  +

And, if I replace [NetApp.Ontapi.Filer.ErrnoException] with  [Netapp.Ontapi.Filer.ErrnoException+EVOLUMEDOESNOTEXIST] it still does not work.

I hope I am not doing something silly here....

1 ACCEPTED SOLUTION

timothyn
3,224 Views

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

View solution in original post

2 REPLIES 2

timothyn
3,225 Views

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

paleon
3,224 Views

dashamalla2,

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.

$hVol = get-naVol -controller $nvController -Names $volName

becomes...

$hVol = get-naVol -controller $nvController -Names $volName -ErrorAction "Stop"

2.  Set the ErrorAction value for all cmdlets to "Stop"

$ErrorActionPreference = Stop

In his script above, Eric Nicholson uses the second method.  However, either method will work.

Please let me know if changing the erroraction fixes the issue.

Bill

Public