Should Get-Member behave differently in Strict Mode?

[HumanEquivalentUnit]

In normal mode, accessing a property that does not exist returns $null. StrictMode disables this and makes it an exception. That is consistent over several commands - except Get-Member which returns $null. This is surprising, and I expected it should also raise an exception. Should it?

Test cases:

PS C:\> Set-StrictMode -Version 2
PS C:\> $x = Get-Item 'C:\windows'
PS C:\> $x.pretend
The property 'pretend' cannot be found on this object. # PropertyNotFoundStrict

PS C:\> $x | Select-Object -ExpandProperty pretend
Select-Object : Property "pretend" cannot be found # ExpandPropertyNotFound

PS C:\> $x | ForEach-Object -MemberName pretend
ForEach-Object : The input name "pretend" cannot be resolved to a member. # PropertyOrMethodNotFound

PS C:\> $x | Where-Object -Property pretend -eq $null
Where-Object : The input name "pretend" cannot be resolved to a property. # PropertyNotFound

PS C:\> $x.foreach('pretend')
The property 'pretend' cannot be found on this object. # PropertyNotFoundStrict

PS C:\> $x | Get-Member -Name pretend    # outputs $null

[vexx32]

I'm half-thinking it's best to leave it so that we have some way of figuring out whether a property exists or not without throwing an exception.
🤷‍♂️

[mklement0]

I see your point, @vexx32. Using an expression you could do [bool] $x.psobject.properties['pretend'] or [bool] $x.psobject.methods['pretendMethod'], however.

@HumanEquivalentUnit, note that Select-Object -ExpandProperty pretend always reports a non-terminating error (per input object that lacks the property), irrespective of the strict-mode setting (strict-mode violations are statement-terminating errors).

[HumanEquivalentUnit]

I doubt it would be possible to change now without breaking existing code; perhaps only document it. But my question is, was that deliberate or accidental?

@mklement0 you might have seen the related discussion #9086 including testing whether properties exist before using them, in strictmode. I didn't note that Select-Object -ExpandProperty always reports errors for absent properties, that is interesting. I did note that Select-Object -Property Nme with a typo, works perfectly fine in strictmode, no errors about absent properties, and does make an object with a property Nme = $null, just as it would in normal mode.

As per the null-soaking issue, if the intent of StrictMode PropertyNotFound exceptions is to guard against typos, avoid propagating $null, or assert the object is the type you expected it to be, this behaviour of Get-Member and normal behaviour of Select-Object -Property, don't seem consistent with it.

[mklement0]

I see your point re Select-Object -Property, @HumanEquivalentUnit.

The tension is between:

• wanting to ensure in strict mode that you've only specified a preexisting property

• the convenience of intentionally creating a property / ensuring its existence across heterogenous input.

Both use cases are valid.

Similarly, with Get-Member, you could argue that Getting something with an (umambiguous, non-wildcard) name that doesn't refer to something existing should fail in strict mode.
It relates to the discussion about having separate Test-* cmdlets if the intent is merely to test existence - see #7498 (comment)

I'm not sure what the right answer is, but I agree that at least updating the docs is called for.

[LeonarddeR]

I stumbled upon this with regard to select-object.

Set-StrictMode -Version latest
$PSVersionTable | select-object `
@{ Name = "Dummy"; Expression = { $_.DoesNotExist } }

I would expect this to fail, or at least have a possibility to make it fail.

[SeeminglyScience]

@LeonarddeR

Problem with that is that

$PSVersionTable | Select-Object @{ n='Dummy'; e={ throw }}

also fails silently

[LeonarddeR]

You're correct. Slightly worrying.

[SeeminglyScience]

Yeah slightly, but that's also how properties tend to work in PS (and you could consider that expression to be somewhat of a property get accessor). e.g.

public class MyObject
{
    public string MyProperty => throw new System.InvalidOperationException();
}

Accessing MyProperty on that object will work mostly the same.

[mklement0]

That's good to know, @SeeminglyScience, but perhaps even more worrying (I know that this ship sailed a long time ago), given that setting properties and method calls do surface exceptions.

As it stands, it is impossible to surface errors from the script blocks of calculated properties.

[microsoft-github-policy-service]

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]

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]

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.