8000 Add a script debugger "break on error" · Issue #2830 · PowerShell/PowerShell · GitHub
[go: up one dir, main page]

Skip to content

Add a script debugger "break on error" #2830

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

Closed
PaulHigin opened this issue Dec 1, 2016 · 8 comments
Closed

Add a script debugger "break on error" #2830

PaulHigin opened this issue Dec 1, 2016 · 8 comments
Labels
Issue-Enhancement the issue is more of a feature request than a bug WG-Interactive-Debugging debugging PowerShell script
Milestone

Comments

@PaulHigin
Copy link
Contributor

It would be good to have the ability to drop into the script debugger on error. This is relatively easy for non-terminating errors since the PowerShell engine continues to run and so the debugger runs. But exceptions are trickier since the process state is unknown. For exceptions thrown by PowerShell (ErrorAction: "Stop") we could stop in the debugger before throwing the exception. It might be possible to have an unhandled exception handler to allow inspection of the runspace on a thrown exception.

@rkeithhill
Copy link
Collaborator

I'd love to wire such a feature up to Visual Studio Code's exception breakpoints.

@lzybkr lzybkr added WG-Interactive-Debugging debugging PowerShell script Issue-Enhancement the issue is more of a feature request than a bug Up-for-Grabs Up-for-grabs issues are not high pr 8000 iorities, and may be opportunities for external contributors labels Dec 2, 2016
@PaulHigin PaulHigin assigned PaulHigin and unassigned PaulHigin Feb 1, 2017
@SteveL-MSFT
Copy link
Member

Consider exposing this as set-psbreakpoint -breakonerror

@SteveL-MSFT SteveL-MSFT added this to the 6.0.0-beta milestone Feb 10, 2017
@rkeithhill
Copy link
Collaborator

Seems like you could install an unhandled exception filter to catch the exception during the first pass - in which case, process state should still be known. I particularly like this old Matt Pietrek article on the subject - https://www.microsoft.com/msj/0197/Exception/Exception.aspx

@PaulHigin
Copy link
Contributor Author

@SteveL-MSFT Agreed.
@rkeithhill It turns out we already have this in the expression IL for exception handling routing (try/catch, trap) and we can use this to hook into the debugger. Still lots of details to work out but this looks very doable.

@PaulHigin
Copy link
Contributor Author

Thanks to @lzybkr for pointing this out.

@SteveL-MSFT SteveL-MSFT removed the Up-for-Grabs Up-for-grabs issues are not high priorities, and may be opportunities for external contributors label Mar 15, 2017
@SteveL-MSFT SteveL-MSFT modified the milestones: 6.0.0-beta1, 6.0.0-beta2 Mar 16, 2017
@SteveL-MSFT SteveL-MSFT modified the milestones: 6.0.0-beta, 6.0.0 May 15, 2017
@joeyaiello joeyaiello modified the milestones: 6.1.0, 6.0.0 May 16, 2017
@SteveL-MSFT SteveL-MSFT removed this from the 6.1.0-Consider milestone Apr 26, 2018
@TylerLeonhardt
Copy link
Member
TylerLeonhardt commented May 22, 2019

@SteveL-MSFT alternative:

Debug-Runspace -BreakOnError
Set-RunspaceDebug -BreakOnError

@JustinGrote
Copy link
Contributor
JustinGrote commented Jul 21, 2019

EDIT: Moving my comments and vscode workaround to PowerShell/vscode-powershell#298

@PaulHigin
Copy link
Contributor Author

This has been implemented by Kirk as an experimental feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Enhancement the issue is more of a feature request than a bug WG-Interactive-Debugging debugging PowerShell script
Projects
None yet
Development

No branches or pull requests

7 participants
0