or not.... sorry unemployed person here

Yep...it really should have been corrected by now.

Came here to say this. I could not figure out why my test was failing. Then I just thought about it for a second. But, following the logic, it does fail.

You are super smart, we get it

The reference solution in C# expected half-up rounding. In other languages, it just expects the default rounding mode of the language. Though, most sunmitted solutions in C# use the default rounding too, this particular feature of C# test is not justified. Unless I miss something, I think it just be aligned on other languages.

null doesn't have property .length

"null has no length"

will keep that in mind, thank you sir

I've added some examples. Are you completely satisfied now?

It's from 2015, which you can see in 'details' page. It's maybe 7.5kyu, but IMO 7 is OK for it.

Ranks cannot be changed.

Are you a wallpaper specialist? If not, make it as simple as possible (it is a 7kyu). You can google "number of rolls for wallpaper".
BTW "FORTH" refers to FORTH language...

Things do not work as you think they are and how you expect them to. I will try to explain.

I would not be surprised, though, if it threw a null pointer exception when compiling.

Exceptions are not thrown during compilation. Exceptions are a runtime thing, and they occur at runtime, when tests are being executed.

[...] continues on to run the remainder of the code

No, it does not. When you check the outcome of the test, you notice a stacktrace:

java.lang.NullPointerException
	at Kata.sum(Kata.java:5)    <<<===== HERE
	at SolutionTest.SumNullArray(SolutionTest.java:44)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  ... snip ...

The stacktrace shows that your solution throws an exception exactly at the line if(numbers.length < 3) return 0;, and not anywhere further.

I would expect, logically, that would resolve to true because a null has no length.

When you attempt to access a member of an object (here: length), and at the moment of the access the object reference points to null, you always get a NullReferenceException. At run time, you can never use a member of null. The expression numbers.length < 3 will throw an exception if numbers is null.

Based on the above, what happens in this piece of code:

if(numbers == null) return 0;
if(numbers.length < 3) return 0;

When numbers is null, it enters the first if and returns 0. When numbers is not null, it continues down to the second line, and eventually further.

Now, this snippet:

if(numbers.length < 3) return 0;
if(numbers == null) return 0;

When numbers is null, the evaluation of the first condition throws an exception, hands down. Your program is unable to access length member of a no-object. Solution crashes, and the test fails because it does not consider the exception a valid ooutcome.
When input is not null, it evaluates the first if. If the condition is not satisfied, it moves to the second line. Since numbers is known to not be null in this place, this condition is always false and execution goes further on.

If something is still not clear, feel free to ask for more explanations on #java channel of Codewars Discord

Could you show the line/piece which fails, but you think it should work?

How would you expect this code to behave: numbers.length < 3 when you know that numbers is null?

Unclear suggestion

That's why it's a numbered list, to establish a priority. What would you clarify?