Ubiquitous -OnError {ScriptBlock} parameter

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"
}

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:

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.
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).

FYI, this RFC proposes a different approach that I believe provides a better method for doing this, for all streams, without introducing a bunch of new common variables: PowerShell/PowerShell-RFC#219. It supercedes the closed RFC196 proposal that is referenced above.

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.

Navigation Menu

Repository navigation

Ubiquitous -OnError {ScriptBlock} parameter #6010

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Ubiquitous -OnError {ScriptBlock} parameter #6010

Description

Activity

felixfbecker commented on May 31, 2019

skycommand commented on Jun 2, 2019

vexx32 commented on Jun 2, 2019

KirkMunro commented on Jun 6, 2019

KirkMunro commented on Jan 13, 2021

microsoft-github-policy-service commented on Nov 16, 2023

microsoft-github-policy-service commented on Nov 16, 2023

microsoft-github-policy-service commented on Nov 16, 2023

microsoft-github-policy-service commented on Nov 23, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions