Repository navigation
Trap statement doesn't take effect when dot-sourced #5342
Description
Activity
With t1.ps1
. ./t2.ps1 1 / 0 Trap { '!!!!! Shame.'; exit 1 } 'after'I get strange result too.
Strange in what way?
When I try your snippet, the in-script
Traptakes effect (it's fine to place it after the offending statement), and the sourced one is still ignored.So it seems to me that both snippets demonstrate the same problem.
I don't see an error for previous command
1/0.Michael Klement (@mklement0) Ilya (@iSazonov)
trapis a lexical construct, scoped to the compile unit (i.e. the script). This is why dot-sourcing a file with atrapstatement doesn't introduce a trap into the caller's environment. When the dot-sourced script exits, its traps are removed. This is also why defining atrapby itself on the command linePS[1] (39) > trap { Write-Host Hello } PS[1] (40) >appears to do nothing. The command executes and then the trap is removed.
NOTE: In V1, we did consider allowing traps defined in dot-sourced scripts or on the command line to persist in the caller's environment however this would have required additional commands to enumerate and manage traps. Due to a lack of time/resources, this was not implemented for V1 and it would be a significant breaking change to do so now.
Reacted by IlyaReacted by boernsenNo additional updates so I'm closing this.
Steve Lee (@SteveL-MSFT): Can you please add the
Documentation Neededlabel so that Bruce Payette (@BrucePay)'s explanation can be rescued from obscurity?- added a commit that references this issue
on Jan 22, 2026 - added a commit that references this issue
on Jan 22, 2026
Defining a
Trapstatement via a dot-sourced script does not work, which is surprising, given that dot-sourcing[1] is generally equivalent to including the referenced script's content directly in a script.Steps to reproduce
Setup:
Content of
t1.ps1:Content of
t2.ps1:Command that reproduces the symptom:
Expected behavior
The
Traphandler should take effect, output the specified string, and exit with exit code1.Actual behavior
The
Traphandler was ignored altogether, due to being dot-sourced rather than being included directly in the script.Environment data
[1] Nomenclature quibble: Why is
.called the dot-sourcing operator, and not just sourcing operator? Contrast this with&, the call operator, which is mercifully not called the "ampersand call operator". Including the somewhat arbitrary syntactic form in the name seems unnecessary.