Repository navigation
try/catch overrides $ErrorActionPreference? #5693
Description
I was very surprised that if the call to 'bar' is done from within try/catch, then its $ErrorActionPreference is ignored.
See the script below. When 'bar' is called errors are ignored as expected, but when doing it within try/catch the errors surface. Is this the expected behavior?
The script below is a simplification of my actual scenario; in my actual scenario 'foo', 'bar' and the call to 'bar' are on different modules/scripts.
function foo($i) {
if ($i -eq 3) {
throw 'error'
}
}
function bar {
$ErrorActionPreference = 'SilentlyContinue'
for ($i = 0; $i -lt 5; $i++) {
Write-Verbose -Verbose $i
foo($i)
}
}
Write-Verbose -Verbose 'No try/catch'
bar
Write-Verbose -Verbose ''
Write-Verbose -Verbose 'With try/catch'
try {
bar
} catch {
Write-Verbose -Verbose $_
}
VERBOSE: No try/catch
VERBOSE: 0
VERBOSE: 1
VERBOSE: 2
VERBOSE: 3
VERBOSE: 4
VERBOSE:
VERBOSE: With try/catch
VERBOSE: 0
VERBOSE: 1
VERBOSE: 2
VERBOSE: 3
VERBOSE: error
Activity
mklement0 commentedon Dec 15, 2017
It's definitely surprising.
Officially - according to the current documentation -
$ErrorActionPreferenceshould only apply to non-terminating errors, whereas it clearly does apply to a script-terminating error triggered byThrowas well (unlike the-ErrorActionparameter) - but apparently not consistently, as your example shows.I've added your symptom to this doc issue , where I'm trying to document PowerShell's de-facto error-handling behavior (and also how it deviates from the current documentation).
narrieta commentedon Dec 15, 2017
Yes, very surprising. I think this can make using 3rd-party modules (that set $ErrorActionPreference) harder to use. In my case, the caller and the function setting $ErrorActionPreference were on different modules, with a call stack about 5 levels deep. It was very surprising to add a try catch around a function in one module, and see errors popping out apparently from nowhere. I knew the section of our code that sets $ErrorActionPreference to 'SilentlyIgnore' (we have legacy code that produces known errors that can be ignored) so it was easy to understand what was happening. When using 3rd-party modules this could be a lot harder.
narrieta commentedon Dec 15, 2017
BTW, I understand that this behavior has been there since V2, when try/catch was introduced, so changing it now may be risky.
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.