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.

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

Ubiquitous -OnError {ScriptBlock} parameter #6010

Open
jpsnover opened this issue Jan 24, 2018 · 4 comments

Comments

@jpsnover
Copy link
Contributor

commented Jan 24, 2018

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

This comment has been minimized.

Copy link
Contributor

commented May 31, 2019

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

This comment has been minimized.

Copy link

commented Jun 2, 2019

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

This comment has been minimized.

Copy link
Contributor

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.

@KirkMunro

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.