You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Set-StrictMode should cause errors to terminate execution. #9591
Set-StrictMode should cause errors to terminate execution.
In most languages with exceptions, an unhandled exception causes the program to terminate. However, Powershell defaults to continuing on when an unhandled exception occurs.
As a result, I think it is currently widely considered a best practice to begin all scripts with:
There is also some discussion in PowerShell/PowerShell-RFC#88 .
I think that whatever the mechanism for causing non-zero exit codes to halt execution, that should also be included in StrictMode.
It's not so much that PS continues on when unhandled exceptions occur... it's that many commands explicity elect to output a non-terminating error for non-serious scenarios. For example, if a particular object coming from pipeline input is mangled / unusable, a non-terminating error is usually written, allowing the rest of the probably OK data to be processed. If instead a specific non-pipelined parameter value is unusable, the error is usually considered terminating as the command cannot reliably process any input.
Strict Mode shouldn't have any bearing on this behaviour, in my opinion, and should remain a separate setting.
"allowing the rest of the probably OK data to be processed" seems contrary to the spirit of StrictMode. Rain Sallow (/u/ta11ow) (@vexx32) you're saying that you usually use Set-StrictMode but not "ErrorActionPreference" = "Stop" ?
It would be interesting to get a sense for what style guides in different organizations look like. I think my big concern is I would advocate any style guide do max strict mode and "ErrorActionPreference" = "Stop" and I think all my coworkers agree. So having them separate settings seems bad since it makes it easy for people who want both to be unaware of one.
I don't think terminating error handling should be a strict-mode feature -- it would be too easy to wreak havoc if someone turned it on and they happened to use modules or scripts that use Set-StrictMode -Version Latest.
There is an alternate proposal on how terminating errors could terminate properly as part of a collection of 4 related RFCs, all included in this PR: PowerShell/PowerShell-RFC#187. That approach is designed to make opting into terminating errors actually terminating by default an explicit decision.
Reacted by Rain Sallow (/u/ta11ow), Keith Hill and Troy Campbell
microsoft-github-policy-service commented on Nov 16, 2023
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 commented on Nov 16, 2023
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 commented on Nov 16, 2023
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.
Activity
vexx32 commentedon May 13, 2019
It's not so much that PS continues on when unhandled exceptions occur... it's that many commands explicity elect to output a non-terminating error for non-serious scenarios. For example, if a particular object coming from pipeline input is mangled / unusable, a non-terminating error is usually written, allowing the rest of the probably OK data to be processed. If instead a specific non-pipelined parameter value is unusable, the error is usually considered terminating as the command cannot reliably process any input.
Strict Mode shouldn't have any bearing on this behaviour, in my opinion, and should remain a separate setting.
KalleOlaviNiemitalo commentedon May 15, 2019
Set-StrictMode -Version 3.0already means something else, although it is undocumented. See MicrosoftDocs/PowerShell-Docs#2135.lukeschlather commentedon May 23, 2019
"allowing the rest of the probably OK data to be processed" seems contrary to the spirit of StrictMode. Rain Sallow (/u/ta11ow) (@vexx32) you're saying that you usually use Set-StrictMode but not "ErrorActionPreference" = "Stop" ?
It would be interesting to get a sense for what style guides in different organizations look like. I think my big concern is I would advocate any style guide do max strict mode and "ErrorActionPreference" = "Stop" and I think all my coworkers agree. So having them separate settings seems bad since it makes it easy for people who want both to be unaware of one.
KirkMunro commentedon Jun 13, 2019
I don't think terminating error handling should be a strict-mode feature -- it would be too easy to wreak havoc if someone turned it on and they happened to use modules or scripts that use
Set-StrictMode -Version Latest.There is an alternate proposal on how terminating errors could terminate properly as part of a collection of 4 related RFCs, all included in this PR: PowerShell/PowerShell-RFC#187. That approach is designed to make opting into terminating errors actually terminating by default an explicit decision.
microsoft-github-policy-service commentedon Nov 16, 2023
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 commentedon Nov 16, 2023
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 commentedon Nov 16, 2023
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 commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.