SDK 8.1.0 Compiler BUG: misleading compiler error!

Seems to be a compiler bug regarding the 'switch' statement.  Converting to an 'if' works as workaround!

I think it's not very nice but understandable. You need to help the compiler with something like:

var prop = Properties.getValue(dataViews[i]) as Number;

this did indeed fix it:

Thanks!

this did indeed fix it:

Thanks!

That has to be the worst, most misleading, compiler error ever!

Although it's been established that talking about root causes, implementation details, and other impractical nonsense is boring and unwanted, the root cause is that switch statement comparisons are implemented using the equals() function [similar to java], rather than "==". This is an understandable choice, as it allows one non-"primitive" object (*) to be compared to another.

So when you write code like this:

switch (x) {
    case 42:
        System.println("42");
        break;
    default;
        System.println("not 42");
        break;
}

(* for this purpose, when I say "primitive" I mean the immutable types in Monkey C which *can* be compared via ==: null, Boolean, String, Number, Long, Float, Double)

[1/5]

it's kinda equivalent to this:

if (x.equals(42)) {
    System.println("42");
} else {
    System.println("not 42");
}

[2/5]

This explains the compiler error message. The result of Properties.getValue *can* be a BluetoothLowEnergy.ScanResult, and the use of BluetoothLowEnergy.ScanResult equals (or anything else in the BluetoothLowEnergy module) would require the requisite permission. If it did return a ScanResult, then your code would crash at runtime. (Ofc it doesn't.)

This also means that if the switch expression value is null, then the case statement code will crash at runtime, since you can't call equals on null.

So actually, knowing how switch works is important after all.

If there's any chance at all that getProperty can return null in your code, you have to avoid the switch statement by null-checking prop beforehand.

[3/5]

Yes, technically if the property in question is tied to a non-optional setting that has a default value, Properties.getValue() should never return null. But we've seen bugs / quirks in the past where Properties.getValue() could return null regardless.

Note that casting prop with as Number actually masks this problem. It tells the compiler that prop is always a Number and can never be null, which means it won't warn you that you're using a possibly null value as switch expression.

A more robust, yet less efficient, solution would be to implement an instanceof Number check. This solution would also handle the case where prop could be null.

[4/5]

e.g.

var prop = Properties.getValue(dataViews[i]); // Number or null
if (prop instanceof Number) { // make type checker happy and avoid crash if prop is null
    switch (prop) {
        case DATA_VIEW_DAILY:
        case DATA_VIEW_DAILY_WIND:
        case DATA_VIEW_DAILY_PRECIPITATION:
        case DATA_VIEW_DAILY_GRAPH_TEMP_POP:
        case DATA_VIEW_DAILY_GRAPH_WIND_PRESS:
            // not allowed
            Properties.setValue(dataViews[i], DATA_VIEW_HOURLY);
            break;
        default:
            break;
    }
}

So the compiler error is not actually misleading, "bad" (in the sense of incorrect) or a bug.

[5/5]

Compiler errors/warnings are supposed to lead one to a solution.  This compiler error scores 0/10 for that purpose.