Handle Piped `$null` In Collection In `process{}`

[mattcargile]

Hello again,

Just had another thought. A $null is foreach-ed away normally. I was thinking it might be nice to alert the user they have $null values in their piped in data. So what do you think about the below approach? Is it how you imagined such a scenario?

Code

function Invoke-HandlePipedNullValue {
    [CmdletBinding()]
    param (
        # Parameter array accepting nulls, empty strings, and whitespace
        [Parameter(Mandatory, ValueFromPipeline)]
        [AllowEmptyString()]
        [AllowNull()]
        [string[]]
        $Value
    )
    begin{
        $canInterrupt = $true
    }
    
    process {
        if ((Test-PSFFunctionInterrupt) -and $canInterrupt) {
            return
        }
        if ($null -eq $Value) {
            $canInterrupt = $false
            Stop-PSFFunction -Message 'I am null but don''t kill the next process block' -Level Error
            return
        }
        foreach ($currentItemName in $Value) {
            "hello i am the current item: $currentItemName"
        }
    }
    
    end {
        # Curious how to handle interruptions here. I can't think of a scenario where I would want to interrupt the below if one item failed in the process block
    }
}

Usage

@($null,'','234325') | Invoke-HandlePipedNullValue

For end{}, my assumption is one would just reset the process{} layer interrupt variable if you had a scenario where an error in the process{} required interruption of the end{}.

[FriedrichWeinmann]

Well, mostly I wonder why you would use Stop-PSFFunction here.
You are not even implementing -EnableException here, so Stop-PSFFunction will never do more than a warning (which I think is the correct approach anyway).

Write-PSFMessage -Level Error -Message 'I am null but don''t kill the next process block'

Alternatively - especially if you just skipped on the -EnableException part here, I think the easiest option is to do this one:

foreach ($n in 1) { Stop-PSFFunction -Message 'I am null but don''t kill the next process block' -Level Error -Continue }

[mattcargile]

I forgot about Write-PSFMessage. I think that would work better. My module and function implement -EnableException so I apologize that I didn't include that. My intention is to have that feature.

The problem with only including the Stop-PSFFunction inside the foreach is that $nulls are silently ignored on piped input. For instance, the below is what happens if you include a $null in the collection to be piped in.

foreach ( $i in $null ) { "i is $i " }

[mattcargile]

The other behavior problem with Write-PSFMessage -EnableException is that it doesn't kill the whole cmdlet.

ni t.psm1 -conf -value @'
function Get-WritePsfEnableException {
    [CmdletBinding()]
    param (
        [switch]$EnableException
    )
    process {
        'before error'
        Write-PSFMessage -Level Error -Message 'I am error' -EnableException $EnableException.IsPresent
        'after error output'
    }
}
'@
ipmo t.psm1 -force
Get-WritePsfEnableException
Get-WritePsfEnableException -EnableException
rm t.psm1 -conf

In both executions, the 'after error output' is returned. So I feel like if I want the $null handling fully on the pipe, I have to derive another variable to handle multiple piped in items and not returning to early without process{}-ing all the items.

Usage like the below does return correctly, though.

try { Write-PSFMessage -Message 'hello world' -Level Error -EnableException } catch { 'fail' }
# 'fail'

[FriedrichWeinmann]

Well, -EnableException on Write-PSFMessage enables non-terminating exceptions, when providing an errorrecord or exception.
Without those, it won't invent a new one.
If your intention is to kill a command, Stop-PSFFunction is what you wanted ;)

The last example triggers catch because of a bad command call - -EnableException is not a switch parameter and expects an input value ...

[mattcargile]

So do you agree with the secondary variable in the process block to handle Stop-PSFFunction outside a loop? Do we even need to care about $nulls that are piped into a process{}'s foreach to alert users or just silently ignore it?

[FriedrichWeinmann]

So do you agree with the secondary variable in the process block to handle Stop-PSFFunction outside a loop?

Not ... really. This is a case beyond the original expectation of the toolkit (which quite a few scenarios were) that in later iterations never got closed (which many others were ). I think in this particular case - where with -EnableException you want to create a new non-terminating exception, we currently need a workaround like this:

if ($null -eq $Value) {
    Write-PSFMessage -Level Error -Message 'I am null but don''t kill the next process block'
    if ($EnableException) { Write-Error 'I am null but don''t kill the next process block' }
    return
}

Ultimately, I'd need (and should) enable Write-PSFMessage to handle this instead, for example with a new switch-parameter like -NewException. New parameter, because breaking change otherwise.

Do we even need to care about $nulls that are piped into a process{}'s foreach to alert users or just silently ignore it?

Generally, I'd ignore it or put in a verbose message, so it's tracked for those who care.

[mattcargile]

Yeah I like -NewException feature. Right now I just implemented the secondary variable. I wanted to be able to kill the cmdlet on any $null and I like knowing if I have $null in some array variable if I piped it in.