X Tutup
The Wayback Machine - https://web.archive.org/web/20240608051155/https://github.com/PowerShell/PowerShell/issues/6010
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Ubiquitous -OnError {ScriptBlock} parameter #6010

Closed
jpsnover opened this issue Jan 24, 2018 · 9 comments
Closed

Ubiquitous -OnError {ScriptBlock} parameter #6010

jpsnover opened this issue Jan 24, 2018 · 9 comments
Labels
Issue-Enhancement the issue is more of a feature request than a bug Resolution-No Activity Issue has had no activity for 6 months or more WG-Language parser, language semantics

Comments

@jpsnover
Copy link
Contributor

jpsnover commented Jan 24, 2018 •
edited by rjmholt

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"
}
@iSazonov iSazonov added Issue-Enhancement the issue is more of a feature request than a bug WG-Language parser, language semantics labels Jan 24, 2018
@SteveL-MSFT SteveL-MSFT added this to the 6.1.0-Consider milestone Jan 24, 2018
@SteveL-MSFT SteveL-MSFT modified the milestones: 6.2.0-Consider, Future Jun 21, 2018
@Jaykul Jaykul mentioned this issue Feb 3, 2019
Closed
@SteveL-MSFT SteveL-MSFT modified the milestones: Future, 6.3-Consider Feb 19, 2019
@SteveL-MSFT SteveL-MSFT mentioned this issue Apr 22, 2019
Merged
11 tasks
@KirkMunro KirkMunro mentioned this issue May 28, 2019
Open
@felixfbecker
Copy link
Contributor

felixfbecker commented May 31, 2019 •
edited

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

@skycommand
Copy link

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.

@vexx32
Copy link
Collaborator

vexx32 commented Jun 2, 2019

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.

@Kriegel Kriegel mentioned this issue Jun 4, 2019
Closed
@KirkMunro
Copy link
Contributor

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

@KirkMunro KirkMunro mentioned this issue Jun 19, 2019
Closed
@rjmholt rjmholt mentioned this issue Aug 8, 2019
Closed
@jtmoree-github-com jtmoree-github-com mentioned this issue Oct 2, 2019
Open
@SteveL-MSFT SteveL-MSFT removed this from the 7.0-Consider milestone Oct 15, 2019
@SteveL-MSFT SteveL-MSFT added this to the Future milestone Jan 13, 2021
@KirkMunro
Copy link
Contributor

KirkMunro commented Jan 13, 2021 •
edited

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.

@ili101 ili101 mentioned this issue Jan 20, 2021
Closed
@microsoft-github-policy-service Microsoft GitHub Policy Service
Copy link
Contributor

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.

1 similar comment
@microsoft-github-policy-service Microsoft GitHub Policy Service
Copy link
Contributor

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.

@microsoft-github-policy-service microsoft-github-policy-service bot added Resolution-No Activity Issue has had no activity for 6 months or more labels Nov 16, 2023
@microsoft-github-policy-service Microsoft GitHub Policy Service
Copy link
Contributor

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.

@microsoft-github-policy-service Microsoft GitHub Policy Service
Copy link
Contributor

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

@microsoft-github-policy-service microsoft-github-policy-service bot removed this from the Future milestone Nov 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Issue-Enhancement the issue is more of a feature request than a bug Resolution-No Activity Issue has had no activity for 6 months or more WG-Language parser, language semantics
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@TylerLeonhardt @KirkMunro @jpsnover @felixfbecker @SteveL-MSFT @skycommand @iSazonov @vexx32
X Tutup