Powershell: Ubiquitous -OnError {ScriptBlock} parameter

Created on 24 Jan 2018  路  4Comments  路  Source: PowerShell/PowerShell

Ubiquitous -OnError {Scriptblock} parameter which would take precedence over -ErrorAction and others. The scriptbock would be called on terminating errors and would be called for every non-terminating error. For non-terminating errors, the scriptblock can control whether to STOP or CONTINUE code execution.

This would unify the processing of terminating vs non terminating errors:

# Nonterminating error
Stop-Process foo* -OnError {
     Write-Host "Had an error."
}

# Terminating error
Start-CmdwithTerminatingError -OnError {
      Write-Host "Had an error."
}



# Terminating errors always terminate but now non-terminating errors are controlled by Continue/Break
# Continue  == -ErrorAction Continue
# Break     == -ErrorAction Stop
# -ErrorAction Debug can be achieved by writing a message, doing a Wait-Debugger and then 
# afterwards you can continue or break.
Stop-Process foo* -OnError {
     Write-Host "Had an error. Continuing"
     Continue
}

Stop-Process foo* -OnError {
     Write-Host "Had an error. Stopping"
     Break
}

Stop-Process foo* -OnError {
     Write-Host "Had an error.  Debug this script"
     Wait-Debugger
     if ((Read-Host "Type 'y' to continue") -eq 'y'){
        Continue
     } else {
        Break
     }
}

Start-CmdwithTerminatingError -OnError {
      Write-Host "Had an error. Stopping or Continuing has the same effect"
      Break
}



# scriptblock is run at the botton - you have the full call stack preserved
stop-process foo* -OnError { 
   Write-Host "PSCALLstack is preserved!"
   Get-PSCallstack
}


# The exception is surfaced through $_ the same as with try/catch
Stop-Process foo* -OnError {
    Write-Host "Error stopping: $($_.TargetObject)`n"
}
Issue-Enhancement WG-Language

Most helpful comment

Just to call it out, PR #8205 is currently in the review process and should be in place in PowerShell 7 shortly (it's just waiting for PR #9825 to finish review and be merged so that automated scripts can be written against the debugger). It adds an ActionPreference.Break enumeration, which allows you to do this:

Stop-Process foo* -ErrorAction Break

That command will automatically enter the debugger on terminating or non-terminating error, and from that point you can check the call stack, step, continue execution, or terminate (quit) the script that is running.

Once that is merged, it will resolves some of the needs identified here (breaking into the debugger and/or checking the callstack on error).

All 4 comments

Really like the idea as there isn't really any good way to handle errors from the error stream. The only way known to me is something like this:

Get-Whatever 2>&1 |
  ForEach-Object {
    if ($_ -is [ErrorRecord]) {
      # handle error
    } else {
      $_
    }
  }

However, the break and continue seem weird to me because this is a scriptblock, not a loop.
Why not continue by default, and break with throw? That would be more intuitive to me

So, how does it work for distinguishing the error type and acting accordingly? Let's say there is a script in which a file has to be deleted. The Remove-Item command might end with an error when:

  1. _The file is not found:_ Well, that's good, right? We wanted the file gone and it is. The script can disregard this and move on.
  2. _Access to the file is denied:_ Not good! We wanted the file gone and it is still alive. The script must not move on.

You would presumably get $_ input into the scriptblock as the error record, so you could pick what to do based on the type of $_.Exception that it receives.

Just to call it out, PR #8205 is currently in the review process and should be in place in PowerShell 7 shortly (it's just waiting for PR #9825 to finish review and be merged so that automated scripts can be written against the debugger). It adds an ActionPreference.Break enumeration, which allows you to do this:

Stop-Process foo* -ErrorAction Break

That command will automatically enter the debugger on terminating or non-terminating error, and from that point you can check the call stack, step, continue execution, or terminate (quit) the script that is running.

Once that is merged, it will resolves some of the needs identified here (breaking into the debugger and/or checking the callstack on error).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rkeithhill picture rkeithhill  路  3Comments

manofspirit picture manofspirit  路  3Comments

Michal-Ziemba picture Michal-Ziemba  路  3Comments

garegin16 picture garegin16  路  3Comments

SteveL-MSFT picture SteveL-MSFT  路  3Comments