dotfiles
dotfiles copied to clipboard
Breakpoints error when using Select-ObjectIndex
About
Select-ObjectIndexsometimes breaks$error- when it does, referencing that index will print nothing in the term
- empty ones also create multiple new
ErrorRecordsevery prompt

Possible Causes
- a stale/corrupt debug environment
- Probably not a design issue -- otherwise why is it working in the same context
- Maybe scope related -- like referencing
$local:errorvs$global:error(Debugging inside and outside modules cope issues) - Is
$errorsa ring buffer? It wraps after index 255. Could overflowing past index255, end up invalidating a previous reference to$error[0]? Or would it copy the original on write?
Because when debugging things, you can easily wrap 255.
To Reproduce
In my testing, it felt like it was split, either: 100% it would reproduce, or 0%
- Be in a breakpoint
- Create some errors, then index it:
- It felt like hitting 0 before 3 was more likely -- so maybe there's a reference in there?
$Error.count # returns 130 # existing errors
$Error | Utility\Select-ObjectIndex 0
# <the first time you get the right error>
$Error | Utility\Select-ObjectIndex 3 # errors don't print
$Error | Utility\Select-ObjectIndex 0 # errors don't print
> Collection was modified, cannot enumerate.
Once it starts, you can only reference the error in some ways. So when debugging it -- make sure your prompt has $error.count in it.
In the screenshot, Select-Object adds 3 errors, every time ( Maybe it hints to the uncaught error being fired inside the formatter? )
# 169!7.2.6
Pwsh> $error | Select-Object -First 3
# 172!7.2.6
Pwsh> $error | select -First 10
#175!7.2.6
Pwsh> $error | select -First 10

Possibly related, I noticed that they end up copying by value, not ref,
$serr = $error does not.
$serr = $error
$serr2 = $error | select -first 3
$serr3 = $error[0..2]
At least in this case, $serr2, $serr3's version did not increase in count, but $serr does.
$serr2.count; $serr.count; $serr3.Count ;1 /0; $serr2.count; $serr.count; $serr3.Count