Summary of the new feature / enhancement
Parameter conflict validation errors (e.g., "Cannot specify both -X and -Y") currently use inconsistent ErrorCategory values across cmdlets:
| Cmdlet |
Conflicting Parameters |
ErrorId |
ErrorCategory |
| Export-Csv / ConvertTo-Csv |
-QuoteFields / -UseQuotes |
CannotSpecifyQuoteFieldsAndUseQuotes |
InvalidData |
| Export-Csv / ConvertTo-Csv |
-IncludeTypeInformation / -NoTypeInformation |
CannotSpecifyIncludeTypeInformationAndNoTypeInformation |
InvalidData |
| Export-Csv |
-Path / -LiteralPath |
CannotSpecifyPathAndLiteralPath |
InvalidData |
| Export-Csv |
-Append / -NoHeader |
CannotSpecifyBothAppendAndNoHeader |
InvalidData |
| Select-String |
-Culture (requires -SimpleMatch) |
CannotSpecifyCultureWithoutSimpleMatch |
InvalidData |
| Format-Table / List / Custom |
-View / -Property |
FormatCannotSpecifyViewAndProperty |
InvalidArgument |
| Format-Wide |
-AutoSize / -Column |
FormatCannotSpecifyAutosizeAndColumns |
InvalidArgument |
Note: Select-String's error is a dependency requirement rather than a mutual exclusion, but it shares the same inconsistency issue.
Standardizing ErrorCategory and ErrorId naming for parameter validation errors would improve consistency and make error handling more predictable for users and scripts.
Key questions for discussion:
- Can a cmdlet parameter be considered an "argument"? If yes,
InvalidArgument would be semantically appropriate. If not, a new InvalidParameter category might be more accurate, though this would require PowerShell Committee approval as a public API change.
- Should ErrorId naming also be standardized? Currently there are two patterns:
CannotSpecify... and FormatCannotSpecify....
Related: #26472 (discussion origin)
Proposed technical implementation details (optional)
Options include:
- Option A: Standardize on
InvalidArgument and FormatCannotSpecify... prefix (align with Format-* cmdlets)
- Option B: Standardize on
InvalidData and CannotSpecify... prefix (align with Csv/Select-String cmdlets)
- Option C: Propose new
InvalidParameter category with unified CannotSpecify... prefix (requires Committee approval, longer timeline)
Summary of the new feature / enhancement
Parameter conflict validation errors (e.g., "Cannot specify both -X and -Y") currently use inconsistent
ErrorCategoryvalues across cmdlets:Note: Select-String's error is a dependency requirement rather than a mutual exclusion, but it shares the same inconsistency issue.
Standardizing
ErrorCategoryandErrorIdnaming for parameter validation errors would improve consistency and make error handling more predictable for users and scripts.Key questions for discussion:
InvalidArgumentwould be semantically appropriate. If not, a newInvalidParametercategory might be more accurate, though this would require PowerShell Committee approval as a public API change.CannotSpecify...andFormatCannotSpecify....Related: #26472 (discussion origin)
Proposed technical implementation details (optional)
Options include:
InvalidArgumentandFormatCannotSpecify...prefix (align with Format-* cmdlets)InvalidDataandCannotSpecify...prefix (align with Csv/Select-String cmdlets)InvalidParametercategory with unifiedCannotSpecify...prefix (requires Committee approval, longer timeline)