What is the recommended way of calling external commands in PowerShell including error handling?

I don't see the reason why you should use Invoke-Expression in this case, as was mentioned by Grok42 in a comment, the reason why the attempt failed is because you need to quote your path and, in addition to that, you'll need to add the call operator & to invoke that path:

Invoke-ExpressionWithErrorHandling "& 'C:\Program Files\Git\cmd\git.exe' version" 

However you can simply invoke the command passed to the -Command argument using the call operator and you can add a second parameter for the arguments that takes ValueFromRemainingArguments:

function Invoke-WithErrorHandling { param ( [Parameter(Mandatory)] [string] $Command, [Parameter(ValueFromRemainingArguments)] [string[]] $Arguments ) & $Command @Arguments if ($LASTEXITCODE -ne 0) { Write-Error "'$Command' exited with exit code '$LASTEXITCODE'" } } Invoke-WithErrorHandling cmd /c 'ping -n 3 google.com & exit 2' # this way would also work but requires escaping of & with a backtick (`) in pwsh 7+ # cause otherwise its interpreted as a job and as a reserved char in pwsh 5.1 :( Invoke-WithErrorHandling cmd /c ping -n 3 google.com `& exit 2 Invoke-WithErrorHandling 'C:\Program Files\Git\cmd\git.exe' version 

• Santiago's helpful answer is promising:

  • It allows you to (mostly) retain regular invocation syntax, with the executable name / path and the arguments for it specified individually.

    • In other words: you only need to prepend Invoke-WithErrorHandling to how you would call your external program directly (albeit without the situational need for & - see this answer).

  • However, there's a caveat:

    • Because Invoke-WithErrorHandling is implemented as an advanced function (by virtue of using a [Parameter()] attribute), it invariably supports common parameters, which take precedence over any pass-through arguments.

    • E.g., Invoke-WithErrorHandling foo.exe -o would result in an error, because the -o matches two common parameters, -OutVariable and -OutBuffer, causing PowerShell to complain about ambiguity.

      • To work around this, such pass-through arguments need to be quoted, e.g., Invoke-WithErrorHandling foo.exe '-o' - but that is both cumbersome and requires you to be aware of which --prefixed pass-through arguments happen to collide with the names of common parameters.

• Your own answer:

  • Requires you to pass an entire command line as a single string, to a different shell, cmd.exe

  • This requires you to obey the syntax of this other shell, in the context of obeying PowerShell's syntax rules first, in order to pass a string with embedded quoting.

  • The syntax rules of the target shell, cmd.exe, differ from PowerShell's, complicating the solution.

  • Additionally, there's the overhead of having to create an additional child process (for cmd.exe), though that may not matter much in practice.

The following avoids the common-parameter problem that affects Santiago's solution, by defining the function as a simple (non-advanced) one that passes all arguments through:

Note:

• As Santiago's solution, the function below is meant to be used with individual arguments that mimic direct-invocation syntax, e.g., to make the function execute git foo, invoke it as
  Invoke-WithErrorHandling git foo

# To create an *alias* for this function that conforms to PowerShell's naming # standard, use, e.g.: # Set-Alias iwe Invoke-WithErrorHandling function Invoke-WithErrorHandling { # Parse the arguments into the executable and the pass-through arguments # for it. $exe, $argsForExe = $Args # Workaround for v7.2-: # Prevents 2> redirections applied to calls to this function # from accidentally triggering a terminating error in PS v7.2- # See bug report at https://github.com/PowerShell/PowerShell/issues/4002 $ErrorActionPreference = 'Continue' # In v7.4+, prevent PowerShell itself from emitting an error in response # to a nonzero exit code reported from a program. $PSNativeCommandUseErrorActionPreference = $false try { if ($MyInvocation.ExpectingInput) { # Relay pipeline input. Note: The input is collected first, in full, # up front, before it is relayed to the target executable. # Also, the v7.4+ ability to pipe raw bytes between two external # executables is unavailable due to using this wrapper function. $input | & $exe $argsForExe } else { & $exe $argsForExe } } catch { throw } # catch is triggered ONLY if $exe can't be found, never for errors reported by $exe itself if ($LASTEXITCODE) { throw "`"$exe`" indicated failure (exit code $LASTEXITCODE)." } } 

Note:

• As requested, the above creates the equivalent of a .NET exception, which is a fatal-by-default script-terminating error, via the throw keyword.

• The function also supports relaying pipeline input to the target executable, albeit - of necessity - such input is collected in memory first, in full.

  • The only way to avoid this would be to use an advanced function, which is not an option, because it would re-introduce the common-parameters problem.

  • Also, the use of a PowerShell wrapper function invariably precludes the PowerShell 7.4+ ability to pipe raw binary data between to external programs (see the bottom section of this answer for details).

• There is still one remaining difference to direct invocation of external programs that cannot be avoided, whether or not the function is advanced.

  • Unquoted arguments containing , (e.g., foo,bar) must be quoted (e.g, 'foo,bar') in order to be passed through correctly; without quoting, the wrapper function receives the ,-separated tokens as separate arguments.

• The above functionality is also available via the Native module's iee function (authored by me):

  • iee additionally compensates for PowerShell's long-standing bug with respect to passing arguments with embedded " characters in Windows PowerShell (whose latest and last version is 5.1.x), which was finally fixed - with selective exceptions - in PowerShell (Core) 7 v7.3+ - see this answer for details.

Alternatively, if you want to pass the command line to execute as a single argument, do not use a string, but a script block (type [scriptblock], literal form { ... }):

Note:

• The following function therefore expects a single, mandatory script-block argument containing the command to execute (and optionally also pipeline input), so that in order to make it execute git foo, you'd call it as
  Invoke-WithErrorHandling { git foo }

# To create an *alias* for this function that conforms to PowerShell's naming # conventions, use, e.g.: # Set-Alias iwe Invoke-WithErrorHandling function Invoke-WithErrorHandling { param( [Parameter(Mandatory, Position=0)] [scriptblock] $ScriptBlock, [Parameter(ValueFromPipeline)] # Optional pipeline input $InputObject ) begin { # Set up a steppable pipeline. $steppablePipeline = $ScriptBlock.GetSteppablePipeline($myInvocation.CommandOrigin) $steppablePipeline.Begin($PSCmdlet) # Workaround for v7.2-: # Prevents 2> redirections applied to calls to this function # from accidentally triggering a terminating error in PS v7.2- # See bug report at https://github.com/PowerShell/PowerShell/issues/4002 $ErrorActionPreference = 'Continue' # In v7.4+, prevent PowerShell itself from emitting an error in response # to a nonzero exit code reported from a program. $PSNativeCommandUseErrorActionPreference = $false } process { # Pass the current pipeline input through. try { $steppablePipeline.Process($_) } catch { throw } } end { $steppablePipeline.End() if ($LASTEXITCODE) { throw "`"$ScriptBlock`" indicated failure (exit code $LASTEXITCODE)." } } } 

Note:

• Unlike the earlier function, this one is an advanced one, which is unproblematic, because the one and only argument specifying the command line to execute cannot collide with common parameters anymore. However, common parameters such as -OutVariable and -ErrorVariable do not function properly, due to the design limitation discussed in GitHub issue #5758

• The notes on the earlier function apply to this one too, except that pipeline input is supported in a streaming fashion by this function (no need to collect all input up front first), by virtue of it being implemented as a proxy (wrapper) function - see this answer for additional information.