Prerequisites
Steps to reproduce
about_Trap states that trap statements may be defined anywhere within a given scope, but always apply to all statements in that scope. When using input processing methods (begin, process, end), variables act as though there is a consistent scope however the trap statement does not. Below is an extended example of this action.
begin {
Write-Output "Block is: begin"
"Scope is: " + (Get-Variable -Name Scope -Scope Private -ErrorAction SilentlyContinue).Value
"Set Scope to : " + (Set-Variable -Name Scope -Scope Private -Value "begin" -Option Private -PassThru).Value
trap {
Write-Output "Block is: trap"
"Scope is: " + (Get-Variable -Name Scope -Scope Private -ErrorAction SilentlyContinue).Value
"Set Scope to : " + (Set-Variable -Name Scope -Scope Private -Value "trap" -Option Private -PassThru).Value
continue
}
}
process {
Write-Output "Block is: process"
"Scope is: " + (Get-Variable -Name Scope -Scope Private -ErrorAction SilentlyContinue).Value
"Set Scope to : " + (Set-Variable -Name Scope -Scope Private -Value "process" -Option Private -PassThru).Value
throw "error"
}
end {
Write-Output "Block is: end"
"Scope is: " + (Get-Variable -Name Scope -Scope Private -ErrorAction SilentlyContinue).Value
"Set Scope to : " + (Set-Variable -Name Scope -Scope Private -Value "end" -Option Private -PassThru).Value
}
Using the trap statement outside of the input processing methods (begin, process, end) causes unexpected token and/or not recognized term errors. A workaround seems to be to use the source or dot operator on the input processing method blocks to bring them into the same scope. I am not sure if this was intended as using this method does not allow continued execution.
trap {
Write-Output "Block is: trap"
"Scope is: " + (Get-Variable -Name Scope -Scope Private -ErrorAction SilentlyContinue).Value
"Set Scope to : " + (Set-Variable -Name Scope -Scope Private -Value "trap" -Option Private -PassThru).Value
continue
}
. {
begin {
Write-Output "Block is: begin"
"Scope is: " + (Get-Variable -Name Scope -Scope Private -ErrorAction SilentlyContinue).Value
"Set Scope to : " + (Set-Variable -Name Scope -Scope Private -Value "begin" -Option Private -PassThru).Value
}
process {
Write-Output "Block is: process"
"Scope is: " + (Get-Variable -Name Scope -Scope Private -ErrorAction SilentlyContinue).Value
"Set Scope to : " + (Set-Variable -Name Scope -Scope Private -Value "process" -Option Private -PassThru).Value
#throw "error"
}
end {
Write-Output "Block is: end"
"Scope is: " + (Get-Variable -Name Scope -Scope Private -ErrorAction SilentlyContinue).Value
"Set Scope to : " + (Set-Variable -Name Scope -Scope Private -Value "end" -Option Private -PassThru).Value
}
}
If it is intended that the trap statement is bound by script blocks, that should be documented as it not currently intuitive.
Expected behavior
Block is: begin
Scope is:
Set Scope to : begin
Block is: process
Scope is: begin
Set Scope to : process
Block is: trap
Scope is:
Set Scope to : trap
Block is: end
Scope is: process
Set Scope to : end
Actual behavior
Block is: begin
Scope is:
Set Scope to : begin
Block is: process
Scope is: begin
Set Scope to : process
Exception: \test-trap.ps1:21
Line |
21 | throw "error"
| ~~~~~~~~~~~~~
| error
Error details
No response
Environment data
Name Value
---- -----
PSVersion 7.2.2
PSEdition Core
GitCommitId 7.2.2
OS Microsoft Windows 10.0.22000
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Visuals
No response
Prerequisites
Steps to reproduce
about_Trap states that trap statements may be defined anywhere within a given scope, but always apply to all statements in that scope. When using input processing methods (begin, process, end), variables act as though there is a consistent scope however the trap statement does not. Below is an extended example of this action.
Using the trap statement outside of the input processing methods (begin, process, end) causes unexpected token and/or not recognized term errors. A workaround seems to be to use the source or dot operator on the input processing method blocks to bring them into the same scope. I am not sure if this was intended as using this method does not allow continued execution.
If it is intended that the trap statement is bound by script blocks, that should be documented as it not currently intuitive.
Expected behavior
Actual behavior
Error details
No response
Environment data
Visuals
No response