Get-TypeData with a non-wildcard type name that matches no loaded type data quietly returns nothing

Follow-up from #7434 and related to #7498.

Note that this is a longstanding, albeit undocumented, behavior, and changing it now may break existing scripts, so there are two possible resolutions:

Conclude that changing this would break too many scripts and therefore make do with documenting the surprising / inconsistent behavior.
Conclude that this is a Bucket 3 change and make the change nonetheless.

The current behavior - quietly returning nothing and signaling success in $? - deviates from the typical behavior of asking for specific entities with literal names, e.g., Get-Item NoSuch.

Steps to reproduce

Ask for nonexistent type data with a type name that doesn't include wildcard characters:

Get-TypeData NoSuchType

Expected behavior

A non-terminating error indicating that no such type data is loaded into the current session.
$? should indicate $False

The error message should be similar to the one for Get-FormatData (which is suboptimal as of this writing), which, modeled on my suggestion here, could be something like:

No extended type data for type name '{0}' has been loaded into the current session.
Note that type names must be specified exactly as defined and are typically full .NET type names.

Actual behavior

Nothing ([System.Management.Automation.Internal.AutomationNull]::Value) is output, and $? reflects $True.

While this behavior may make sense for wildcard-based arguments, it doesn't for literal ones.

Compare this to the behavior of cmdlets such as Get-Item, Get-ChildItem, Get-Content, ..., which all fail if a given non-wildcard path doesn't identify an existing file.

Environment data

PowerShell Core v6.1.0-preview.4 on macOS 10.13.6
PowerShell Core v6.1.0-preview.4 on Ubuntu 16.04.4 LTS
PowerShell Core v6.1.0-preview.4 on Microsoft Windows 10 Pro (64-bit; Version 1803, OS Build: 17134.165)
Windows PowerShell v5.1.17134.165 on Microsoft Windows 10 Pro (64-bit; Version 1803, OS Build: 17134.165)

I really like the idea of the change, but I believe it will break a lot of existing scripts. Take this function for example.

function Test-Function {
    [CmdletBinding()]
    param()
    begin {
        # Arbitrary intialization code
        if (-not (Get-Module ModuleThatMightChangeCodePath)) {
            Write-Warning 'Recommended module was not found'
        }
    }
    end {
        if ($false) {
            # Conditional error hit, caller can use `ErrorAction` to determine how this is handled.
            Write-Error 'Possible problem!'
        }

        # Do real work. This won't be hit if Get-Module writes a non-terminating error and
        # ErrorAction is stop
        return $true
    }
}

# Returns $true if condition is not hit.
Test-Function -ErrorAction Stop

function Get-Module {
    [CmdletBinding()]
    param([string] $Name)
    end {
        Write-Error 'Not found'
    }
} 

# Always fails during initialization
Test-Function -ErrorAction Stop

This is something I do pretty frequently. Use a command like Get-Module while doing some validation and then continue on with the rest of the command. Now since the error Get-Module would throw is non terminating, alone it doesn't really affect anything. But if I use this function in a script, and I expect to be able to force that expected error to be terminating, that function breaks unexpectedly.

I suspect this is a pretty common pattern, and the discussed change would significantly hurt script portability if it was made across the board.

In the community call, it was mentioned that there really should be Test-Module function to do it. The problem is the breaking change.

I think we should take a step back from these types of changes and focus on a deprecation process to manage breaking changes. Upgrading versions should require minimal changes to existing code to make it easy to update to incremental releases and have warnings and error messages to help a scripter update their code.

For example, this fix could have a warning to migrate to a new Test-Module cmdlet if trying to test for a condition.

@PowerShell/powershell-committee reviewed this, by itself it does break the breaking change contract. However, in this specific case we agree the current behavior is wrong and inconsistent with our desired intent. Agree that this is a bucket 3 risk and don't expect users to leverage this cmdlet in automation, so we are ok with accepting this change.

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.

Navigation Menu

Repository navigation

Get-TypeData with a non-wildcard type name that matches no loaded type data quietly returns nothing #7521

Steps to reproduce

Expected behavior

Actual behavior

Environment data

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Get-TypeData with a non-wildcard type name that matches no loaded type data quietly returns nothing #7521

Description

Steps to reproduce

Expected behavior

Actual behavior

Environment data

Activity

SeeminglyScience commented on Aug 17, 2018

dragonwolf83 commented on Aug 18, 2018

SteveL-MSFT commented on Nov 7, 2018

microsoft-github-policy-service commented on Nov 16, 2023

microsoft-github-policy-service commented on Nov 16, 2023

microsoft-github-policy-service commented on Nov 16, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions