I've been writing about the different parameter validation attributes that you can use in your PowerShell scripting. One that I use in practically every script is [ValidateNotNullorEmpty()]. This validation will ensure that something is passed as a parameter value. I'm not talking about making a parameter mandatory; only that if the user decides to use the parameter that something is passed. Let's look at my demo.
ManageEngine ADManager Plus - Download Free Trial
Exclusive offer on ADManager Plus for US and UK regions. Claim now!
#requires -version 2.0
Param (
[Parameter(Position=0,Mandatory=$True,HelpMessage="Enter a process name like lsass")]
[ValidateNotNullorEmpty()]
[string]$Name,
[Parameter(Position=1)]
[ValidateNotNullorEmpty()]
[string]$Computername=$env:computername
)
Try {
Get-Process -Name $name -ComputerName $computername -errorAction "Stop" | Select *,
@{Name="Runtime";Expression={(Get-Date)-$_.StartTime}}
}
Catch {
Write-Warning $_.Exception.Message
}
I've used the attribute on both parameters. The first parameter I've also made mandatory which makes it more likely that something will be entered. But if not, then the script will fail.
I would get a similar message if the user forgot to complete the command.
Even though I'm using a default value for Computername, as soon as the parameter is detected PowerShell assumes I'm going to use a different value.
Validation should work for missing values, a variable that might be null, or in general anything that is meaningless. However, it won't prevent something quirky like this:
PS S:\> $p=" "
PS S:\> .\demo-ValidateNotNull.ps1 -name $p
WARNING: Cannot find a process with the name " ". Verify the process name and
call the cmdlet again.
The variable, while semantically meaningless to us, is not null or empty but a string of 1 space. If there's the chance you might run into this situation then you can add additional validation checks to the parameter.
If you'd like, feel free to download Demo-ValidateNotNull and see for yourself.