Error message for 1/\$null

1. ## Error message for 1/\$null

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

My System Specs

2. ## Re: Error message for 1/\$null

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

My System Specs

3. ## Re: Error message for 1/\$null

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

My System Specs

4. ## Re: Error message for 1/\$null

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
>
>

My System Specs

5. ## Re: Error message for 1/\$null

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"}

My System Specs

6. ## Re: Error message for 1/\$null

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\/\/

My System Specs

7. ## Re: Error message for 1/\$null

"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

My System Specs

8. ## Re: Error message for 1/\$null

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
>>
>>

>
>

My System Specs

9. ## Re: Error message for 1/\$null

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
>>>
>>>

>>
>>

My System Specs

10. ## Re: Error message for 1/\$null

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
>

My System Specs

Page 1 of 2 12 Last

Error message for 1/\$null

 Similar Threads Thread Forum PowerShell .NET General Vista performance & maintenance PowerShell Vista installation & setup