If I type



1/$null

I get an error message about attempting to divide by zero. But $null
is not zero, in my understanding.

Does the error message need to be corrected?

Andrew Watt MVP

Andrew Watt [MVP] wrote:
> If I type
>
> 1/$null
>
> I get an error message about attempting to divide by zero. But $null
> is not zero, in my understanding.
>
> Does the error message need to be corrected?

I think this is by design, because PS does many automatic type conversions,
and $null converts to zero:

[PS] [int]$null
0
[PS] $null + 2
2
[PS] 5/'2'
2,5
[PS] [math]::abs($null)
0

On Mon, 22 May 2006 20:21:20 +0300, "Jouko Kynsijärvi"
<jouko.kynsijarvi@nospam.nospam> wrote:

>Andrew Watt [MVP] wrote:
>> If I type
>>
>> 1/$null
>>
>> I get an error message about attempting to divide by zero. But $null
>> is not zero, in my understanding.
>>
>> Does the error message need to be corrected?
>
>I think this is by design, because PS does many automatic type conversions,
>and $null converts to zero:
>
>[PS] [int]$null
>0
>[PS] $null + 2
>2
>[PS] 5/'2'
>2,5
>[PS] [math]::abs($null)
>0

Hi Jouko,

But it's not consistent.

Try

1/$null; trap{"This is trapped"}

and

1/0; trap{"This is trapped"}

and you see two different results. At least I do.

If conversion of 0 to $null is by design I would like to better
understand the logic behind that design decision. To my way of
thinking $null and 0 are two different things. At least they ought to
be.

Andrew Watt MVP

That's pretty strange. Null represents an unknown value; any number divided
by an unknown value, is by definition, unknown. Most languages I've worked
with would give $null as an answer. This looks like a bug to me.

- Oisin

"Jouko Kynsijärvi" <jouko.kynsijarvi@nospam.nospam> wrote in message
news:O1BjbQcfGHA.764@TK2MSFTNGP05.phx.gbl...
> Andrew Watt [MVP] wrote:
>> If I type
>>
>> 1/$null
>>
>> I get an error message about attempting to divide by zero. But $null
>> is not zero, in my understanding.
>>
>> Does the error message need to be corrected?
>
> I think this is by design, because PS does many automatic type
> conversions, and $null converts to zero:
>
> [PS] [int]$null
> 0
> [PS] $null + 2
> 2
> [PS] 5/'2'
> 2,5
> [PS] [math]::abs($null)
> 0
>
>

Andrew Watt [MVP] wrote:
> But it's not consistent.
>
> Try
>
> 1/$null; trap{"This is trapped"}
>
> and
>
> 1/0; trap{"This is trapped"}
>
> and you see two different results. At least I do.
>
> If conversion of 0 to $null is by design I would like to better
> understand the logic behind that design decision. To my way of
> thinking $null and 0 are two different things. At least they ought to
> be.

I agree that $null and zero are different. Infact i would really like if PS
had full support for Nullable<T> everywhere (+, -, /, *, -and, -or etc). I'm
just reporting my findings...

Just a wild guess: could this difference be because 0 is a literal and $null
is a variable? So 1/0 gets caught at "parse/compile" time, but 1/$null and
1/$zero at "runtime":

[PS] 1/$null; trap{"This is trapped"}
This is trapped
Attempted to divide by zero.
At line:1 char:3
+ 1/$ <<<< null; trap{"This is trapped"}

[PS] 1/0; trap{"This is trapped"}
Attempted to divide by zero.
At line:1 char:3
+ 1/0 <<<< ; trap{"This is trapped"}

[PS] $zero = 0; 1/$zero; trap{"This is trapped"}
This is trapped
Attempted to divide by zero.
At line:1 char:14
+ $zero = 0; 1/$ <<<< zero; trap{"This is trapped"}

Jouko Kynsijärvi wrote:
> Andrew Watt [MVP] wrote:
>> But it's not consistent.
>>
>> Try
>>
>> 1/$null; trap{"This is trapped"}
>>
>> and
>>
>> 1/0; trap{"This is trapped"}
>>
>> and you see two different results. At least I do.
>>
>> If conversion of 0 to $null is by design I would like to better
>> understand the logic behind that design decision. To my way of
>> thinking $null and 0 are two different things. At least they ought to
>> be.
>
> I agree that $null and zero are different. Infact i would really like if PS
> had full support for Nullable<T> everywhere (+, -, /, *, -and, -or etc). I'm
> just reporting my findings...
>
> Just a wild guess: could this difference be because 0 is a literal and $null
> is a variable? So 1/0 gets caught at "parse/compile" time, but 1/$null and
> 1/$zero at "runtime":
>
> [PS] 1/$null; trap{"This is trapped"}
> This is trapped
> Attempted to divide by zero.
> At line:1 char:3
> + 1/$ <<<< null; trap{"This is trapped"}
>
> [PS] 1/0; trap{"This is trapped"}
> Attempted to divide by zero.
> At line:1 char:3
> + 1/0 <<<< ; trap{"This is trapped"}
>
> [PS] $zero = 0; 1/$zero; trap{"This is trapped"}
> This is trapped
> Attempted to divide by zero.
> At line:1 char:14
> + $zero = 0; 1/$ <<<< zero; trap{"This is trapped"}
>
>

look at the difference in parameterbinding
in the 2 cases


MowPS>Trace-Command parameterbinding -opt all {1/0; trap{"This is
trapped"}} -pshost
Attempted to divide by zero.
At line:1 char:44
+ Trace-Command parameterbinding -opt all {1/0 <<<< ; trap{"This is
trapped"}} -pshost


MowPS>Trace-Command parameterbinding -opt all {1/$null; trap{"This is
trapped"}} -pshost
DEBUG: ParameterBinding Information: 0 : BIND PIPELINE object to
parameters: [Out-Default]
DEBUG: ParameterBinding Information: 0 : PIPELINE object TYPE =
[System.Management.Automation.ErrorRecord]
DEBUG: ParameterBinding Information: 0 : RESTORING pipeline
parameter's original values
DEBUG: ParameterBinding Information: 0 : Parameter [InputObject]
PIPELINE INPUT ValueFromPipeline NO COERCION
DEBUG: ParameterBinding Information: 0 : BIND arg [Attempted to
divide by zero.] to parameter [InputObject]
DEBUG: ParameterBinding Information: 0 : BIND arg [Attempted to
divide by zero.] to param [InputObject] SUCCESSFUL
DEBUG: ParameterBinding Information: 0 : MANDATORY PARAMETER CHECK on
cmdlet [Out-Default]
DEBUG: ParameterBinding Information: 0 : CALLING ProcessRecord
DEBUG: ParameterBinding Information: 0 : BIND NAMED cmd line args
[out-lineoutput]
DEBUG: ParameterBinding Information: 0 : BIND arg
[Microsoft.PowerShell.Commands.Internal.Format.ConsoleLineOutput] to
parameter
[LineOutput]
DEBUG: ParameterBinding Information: 0 : COERCE arg type
[Microsoft.PowerShell.Commands.Internal.Format.ConsoleLineOutput] to
[System.Object]
DEBUG: ParameterBinding Information: 0 : The parameter
is of type [System.Object] so the parameter value is the current
input object.
DEBUG: ParameterBinding Information: 0 : BIND arg
[Microsoft.PowerShell.Commands.Internal.Format.ConsoleLineOutput] to param
[LineOutput] SUCCESSFUL
DEBUG: ParameterBinding Information: 0 : BIND POSITIONAL cmd line
args [out-lineoutput]
DEBUG: ParameterBinding Information: 0 : MANDATORY PARAMETER CHECK
on cmdlet [out-lineoutput]
DEBUG: ParameterBinding Information: 0 : CALLING BeginProcessing
DEBUG: ParameterBinding Information: 0 : BIND PIPELINE object to
parameters: [out-lineoutput]
DEBUG: ParameterBinding Information: 0 : PIPELINE object TYPE =
[System.Management.Automation.ErrorRecord]
DEBUG: ParameterBinding Information: 0 : RESTORING pipeline
parameter's original values
DEBUG: ParameterBinding Information: 0 : Parameter [InputObject]
PIPELINE INPUT ValueFromPipeline NO COERCION
DEBUG: ParameterBinding Information: 0 : BIND arg [Attempted to
divide by zero.] to parameter [InputObject]
DEBUG: ParameterBinding Information: 0 : BIND arg [Attempted
to divide by zero.] to param [InputObject] SUCCESSFUL
DEBUG: ParameterBinding Information: 0 : MANDATORY PARAMETER CHECK
on cmdlet [out-lineoutput]
DEBUG: ParameterBinding Information: 0 : CALLING ProcessRecord
DEBUG: ParameterBinding Information: 0 : BIND NAMED cmd line
args [format-default]
DEBUG: ParameterBinding Information: 0 : BIND POSITIONAL cmd
line args [format-default]
DEBUG: ParameterBinding Information: 0 : MANDATORY PARAMETER
CHECK on cmdlet [format-default]
DEBUG: ParameterBinding Information: 0 : CALLING BeginProcessing
DEBUG: ParameterBinding Information: 0 : BIND PIPELINE object to
parameters: [format-default]
DEBUG: ParameterBinding Information: 0 : PIPELINE object
TYPE = [System.Management.Automation.ErrorRecord]
DEBUG: ParameterBinding Information: 0 : RESTORING pipeline
parameter's original values
DEBUG: ParameterBinding Information: 0 : Parameter
[InputObject] PIPELINE INPUT ValueFromPipeline NO COERCION
DEBUG: ParameterBinding Information: 0 : BIND arg [Attempted
to divide by zero.] to parameter [InputObject]
DEBUG: ParameterBinding Information: 0 : BIND arg
[Attempted to divide by zero.] to param [InputObject] SUCCESSFUL
DEBUG: ParameterBinding Information: 0 : MANDATORY PARAMETER
CHECK on cmdlet [format-default]
DEBUG: ParameterBinding Information: 0 : CALLING ProcessRecord
Attempted to divide by zero.
At line:1 char:44
+ Trace-Command parameterbinding -opt all {1/$ <<<< null; trap{"This is
trapped"}} -pshost
This is trapped

You see in the second case the Shell uses much more power to get to the
error ;-)


greetings, /\/\o\/\/

"Jouko Kynsijärvi" <jouko.kynsijarvi@nospam.nospam> wrote in message
news:e6YIE2cfGHA.5100@TK2MSFTNGP05.phx.gbl...
> I agree that $null and zero are different. Infact i would really like if
> PS had full support for Nullable<T> everywhere (+, -, /, *, -and, -or
> etc). I'm just reporting my findings...

Along those lines I would love to see support for the ?? operator. I would
love to be able to do stuff like this:

$logDir = $env:LogDir ?? $env:Temp

Now that is terse compared to:

if ($logDir -ne $null) {
$logDir = $env:LogDir
}
else {
$logDir = $env:Temp
}

Of course, this also begs having the tertiary operator - (foo -eq bar ? $a :
$b).

BTW, if anybody agrees then vote on:

https://connect.microsoft.com/feedba...edbackID=53061
and
https://connect.microsoft.com/feedba...edbackID=53059

--
Keith

but with the Trap, I think that latter ($null) behavior is correct,

in this first sample I would expect to error to get trapped also.
as I trap everything.

MowPS>trap{"This is trapped";continue};1/0;'end'
Attempted to divide by zero.
At line:1 char:36
+ trap{"This is trapped";continue};1/0 <<<< ;'end'

MowPS>trap{"This is trapped";continue};1/$null;'end'
This is trapped
end

the second example is what I would expect.

gr /\/\o\/\/

Oisin G. wrote:
> That's pretty strange. Null represents an unknown value; any number divided
> by an unknown value, is by definition, unknown. Most languages I've worked
> with would give $null as an answer. This looks like a bug to me.
>
> - Oisin
>
> "Jouko Kynsijärvi" <jouko.kynsijarvi@nospam.nospam> wrote in message
> news:O1BjbQcfGHA.764@TK2MSFTNGP05.phx.gbl...
>> Andrew Watt [MVP] wrote:
>>> If I type
>>>
>>> 1/$null
>>>
>>> I get an error message about attempting to divide by zero. But $null
>>> is not zero, in my understanding.
>>>
>>> Does the error message need to be corrected?
>> I think this is by design, because PS does many automatic type
>> conversions, and $null converts to zero:
>>
>> [PS] [int]$null
>> 0
>> [PS] $null + 2
>> 2
>> [PS] 5/'2'
>> 2,5
>> [PS] [math]::abs($null)
>> 0
>>
>>
>
>

MowPS>trap{"This is trapped";continue};"$(1/0)";'end'
This is trapped
end

/\/\o\/\/ wrote:
> but with the Trap, I think that latter ($null) behavior is correct,
>
> in this first sample I would expect to error to get trapped also.
> as I trap everything.
>
> MowPS>trap{"This is trapped";continue};1/0;'end'
> Attempted to divide by zero.
> At line:1 char:36
> + trap{"This is trapped";continue};1/0 <<<< ;'end'
>
> MowPS>trap{"This is trapped";continue};1/$null;'end'
> This is trapped
> end
>
> the second example is what I would expect.
>
> gr /\/\o\/\/
>
> Oisin G. wrote:
>> That's pretty strange. Null represents an unknown value; any number
>> divided by an unknown value, is by definition, unknown. Most languages
>> I've worked with would give $null as an answer. This looks like a bug
>> to me.
>>
>> - Oisin
>>
>> "Jouko Kynsijärvi" <jouko.kynsijarvi@nospam.nospam> wrote in message
>> news:O1BjbQcfGHA.764@TK2MSFTNGP05.phx.gbl...
>>> Andrew Watt [MVP] wrote:
>>>> If I type
>>>>
>>>> 1/$null
>>>>
>>>> I get an error message about attempting to divide by zero. But $null
>>>> is not zero, in my understanding.
>>>>
>>>> Does the error message need to be corrected?
>>> I think this is by design, because PS does many automatic type
>>> conversions, and $null converts to zero:
>>>
>>> [PS] [int]$null
>>> 0
>>> [PS] $null + 2
>>> 2
>>> [PS] 5/'2'
>>> 2,5
>>> [PS] [math]::abs($null)
>>> 0
>>>
>>>
>>
>>

If you don't mind using a prefix-style, you can use this for your ternary
operator:

[C:\temp\powershell]
PS:27 > function ?? { if($args[0]) { $args[0] } else { $args[1] } }

[C:\temp\powershell]
PS:28 > ?? $null 5
5

[C:\temp\powershell]
PS:29 > ?? 5 $null
5

[C:\temp\powershell]
PS:30 > ?? $null $null

[C:\temp\powershell]
PS:31 > ?? 5 5
5

--
Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.


"Keith Hill [MVP]" <r_keith_hill@no.spam.thank.u.hotmail.com> wrote in
message news:uWHLHZdfGHA.3900@TK2MSFTNGP05.phx.gbl...
> "Jouko Kynsijärvi" <jouko.kynsijarvi@nospam.nospam> wrote in message
> news:e6YIE2cfGHA.5100@TK2MSFTNGP05.phx.gbl...
>> I agree that $null and zero are different. Infact i would really like if
>> PS had full support for Nullable<T> everywhere (+, -, /, *, -and, -or
>> etc). I'm just reporting my findings...
>
> Along those lines I would love to see support for the ?? operator. I
> would love to be able to do stuff like this:
>
> $logDir = $env:LogDir ?? $env:Temp
>
> Now that is terse compared to:
>
> if ($logDir -ne $null) {
> $logDir = $env:LogDir
> }
> else {
> $logDir = $env:Temp
> }
>
> Of course, this also begs having the tertiary operator - (foo -eq bar ? $a
> : $b).
>
> BTW, if anybody agrees then vote on:
>
> https://connect.microsoft.com/feedba...edbackID=53061
> and
> https://connect.microsoft.com/feedba...edbackID=53059
>
> --
> Keith
>