Potential Null Pointer Access
-
@ben_lubar said in Potential Null Pointer Access:
Is this something you can trivially rewrite to start the loop with the assignment instead of the null check? Not having to do a null check at all would probably fix your problem.
A common case for this is typically processing the results of a query where multiple rows correspond to a single object. So what I probably need to do to keep this from being annoying is assign some kind of sentinel / dummy value that cannot occur.
At the top of the loop I check to see if the current row matches the current object being processed. First time through, that's null and it gets assigned to some value, so anywhere below that in the loop it's guaranteed to be true. But the compiler just isn't smart enough to notice all of that.
I was just hoping for a super easy way to make it smarter about it in one place rather than all of the places where it happens.
-
@Zecc said in Potential Null Pointer Access:
My question now is why not just change the conditional to check for i != 0?
Well, like most modern
for
loops, the real loop is most likely a for each style loop so there isn't really ani
in there to test.
-
@boomzilla said in Potential Null Pointer Access:
@ben_lubar said in Potential Null Pointer Access:
Is this something you can trivially rewrite to start the loop with the assignment instead of the null check? Not having to do a null check at all would probably fix your problem.
A common case for this is typically processing the results of a query where multiple rows correspond to a single object. So what I probably need to do to keep this from being annoying is assign some kind of sentinel / dummy value that cannot occur.
At the top of the loop I check to see if the current row matches the current object being processed. First time through, that's null and it gets assigned to some value, so anywhere below that in the loop it's guaranteed to be true. But the compiler just isn't smart enough to notice all of that.
I was just hoping for a super easy way to make it smarter about it in one place rather than all of the places where it happens.
It seems like your IDE wants to make your life harder. Is the function in the condition something you can inline without making the line wider than your screen?
-
Is it the IDE warnings that you care about, or just project warnings from somewhere - because there's the checker framework that will let you do some pretty reasonable things and would recognize this pattern pretty reasonably, I think.
(Also, as a side note, in the totally unhelpful "well, you wouldn't have this problem if you used X instead" vein, TypeScript has no problem with this):
function isNonNull<T>(foo: T | undefined): foo is T { return foo != null; } function onlyNonNullStrings(x: string) { } const x = Math.random() > 0.5 ? "hello" : undefined; if (isNonNull(x)) { onlyNonNullStrings(x); }
-
@svieira said in Potential Null Pointer Access:
const x = Math.random() > 0.5 ? "hello" : undefined;
I see that TypeScript uses JavaScript's dumb definition of "constant" which is "not constant".
And apparently it's either untyped or Microsoft made TypeScript's compiler smarter for ternary expressions than they made the C# compiler.
-
@ben_lubar said in Potential Null Pointer Access:
And apparently it's either untyped or Microsoft made TypeScript's compiler smarter for ternary expressions than they made the C# compiler.
var rand = new Random(); var x = rand.Next(2) > 0 ? "hello" : null;
What's wrong with the C# compiler?
-
@Jaloopa said in Potential Null Pointer Access:
@ben_lubar said in Potential Null Pointer Access:
And apparently it's either untyped or Microsoft made TypeScript's compiler smarter for ternary expressions than they made the C# compiler.
var rand = new Random(); var x = rand.Next(2) > 0 ? "hello" : null;
What's wrong with the C# compiler?
If
string
is a nullable type in TypeScript, your original example doesn't work.If not, try doing that with a type that can be used with
?
likeint
.
-
@ben_lubar Ah, I see what you mean. It wasn't my original example though
-
@ben_lubar said in Potential Null Pointer Access:
And apparently it's either untyped or Microsoft made TypeScript's compiler smarter for ternary expressions than they made the C# compiler.
It's not so much the TypeScript one is smarter, more that C# has a stricter type system. C# has no automatic conversion that allows
test ? 7 : null;
to work, as there's no automatic mapping fromnull
toint
.
-
@RaceProUK said in Potential Null Pointer Access:
@ben_lubar said in Potential Null Pointer Access:
And apparently it's either untyped or Microsoft made TypeScript's compiler smarter for ternary expressions than they made the C# compiler.
It's not so much the TypeScript one is smarter, more that C# has a stricter type system. C# has no automatic conversion that allows
test ? 7 : null;
to work, as there's no automatic mapping fromnull
toint
.The thing that's weird to me is that
int? foo = test ? 7 : null;
also causes a compiler error.
-
@ben_lubar Yep, because there's no auto conversion from
null
toint
;)var foo = test ? 7 : new int?();
works though.The reason
int? foo = test ? 7 : null;
doesn't work is becauseint?
is shorthand forNullable<int>
, which, even though you can assignnull
to it, is a value type, not a reference type.
-
@ben_lubar said in Potential Null Pointer Access:
The thing that's weird to me is that
int? foo = test ? 7 : null;
also causes a compiler error.When the place you store an expression has an influence on the expression itself, that way lay madness. The problem is entirely on the right side of the equal sign, and has no business being influenced by the left side.
I could use @RaceProUK's suggestion, but by habit I use
test ? (int?)7 : null
instead.
-
@Medinoc said in Potential Null Pointer Access:
that way lay madness
Also known as “some version of Perl”…