Add an overload to System.Management.Automation.Cmdlet.WriteError that accepts an System.Exception

During the runtime of a advanced Function the function developer may use .NET classes which produce .NET exceptions.

To rethrow an Exception in an advanced Function we can use Write-Error, Throw or $PSCmdlet.WriteError().

To set the advanced Function as origin of the Error AND to make the .NET Exception an ErrorRecord Object $PSCmdlet.WriteError() is the best candidate.

currently the user has to make an cumbersome switch inside the Catch block to catch .NET Exception Types and ErrorRecord Types.

Function Get-ErrorHandling {

    [CmdletBinding()]
    Param()

    Process {
       Try {
           
           $File = Get-Item 'C:\no\such.txt' -ErrorAction 'Stop'
                      
           [double]::Parse('Hello')
             
       } Catch {

           If($_ -is [System.Management.Automation.ErrorRecord]) {
              $PSCmdlet.WriteError($_)
           } Else {
              $PSCmdlet.WriteError((New-Object System.Management.Automation.ErrorRecord -ArgumentList $_))
           }
       }
    }
}

So $PSCmdlet.WriteError() needs an overload that accepts a .NET Exception and makes it into an ErrorRecord with an InvocationInfo of the advanced the Function here Named “Get-ErrorHandling” as source.

[SeeminglyScience]

Yeah I know, the point I was trying (poorly) to make was that those details are lost (or rather replaced with meaningless defaults). If such an overload was added, it could lead to a significant amount of first time binary module writers skipping all of those details completely.

In general my opinion is that if you want to emit a “proper” error (one that reflects the users context) then those details should be specified. I would like to see an overload like WriteError(Exception,string,ErrorCategory,object) that just creates the ErrorRecord for you while still requiring the information.

Also I don’t really see a problem with adding a switch to Write-Error to change context.

[vexx32]

As far as I know, the only time you’ll get a raw exception is if there’s a parse error in the PowerShell script itself; i.e., PowerShell’s own language parser throws the exception. In most cases this won’t surface, but if it does I believe ParseExceptions have an ErrorRecord property that you can make use of for a bit of an easier time with this kind of case. 🙂

Do you know of any reproducible examples that produce an Exception object within the catch block?