Potential Null Pointer Access

boomzilla

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

boomzilla

@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 an i in there to test.

ben_lubar

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

svieira

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);
}

ben_lubar

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

Jaloopa

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

ben_lubar

@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 ? like int.

Jaloopa

@ben_lubar Ah, I see what you mean. It wasn't my original example though

RaceProUK

@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 from null to int.

ben_lubar

@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 from null to int.

The thing that's weird to me is that int? foo = test ? 7 : null; also causes a compiler error.

RaceProUK

@ben_lubar Yep, because there's no auto conversion from null to int ;) var foo = test ? 7 : new int?(); works though.

The reason int? foo = test ? 7 : null; doesn't work is because int? is shorthand for Nullable<int>, which, even though you can assign null to it, is a value type, not a reference type.

Medinoc

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

dkf

@Medinoc said in Potential Null Pointer Access:

that way lay madness

Also known as “some version of Perl”…