False negative inspector for ternaries

[Eric Kintzer]

Following valid Apex code generates inspector redline

    public virtual String getTransactionId() {
        return transactionId == null 
                   ? transactionId = String.valueOf(System.currentTimeMillis()) + '_' + UserInfo.getName() 
                   : transactionId;
    }

I'll be the first to admit that this isn't a common Apex pattern but if you're into semi-colon minimization :-) like me...

[Scott Wells]

Thanks, Eric. Actually I use ternaries all the time and haven't seen such an issue, so I don't think it's necessarily an issue with type inference for ternary operators in general; it's likely something specific to the types of expressions being evaluated for one or more components of the ternary operator in this specific example. In fact, the error message you're getting indicates that it's a parser error and not a type inference issue. Let me take a look based on the example you've provided and hopefully it'll be obvious. At first glance I'm thinking that I'm not treating the assignment expression properly.

[Scott Wells]

Yep, that's what's going on. For some reason the parser is thinking that transactionId in transactionId = String.valueOf(...) is the beginning of a reference expression instead of an assignment expression. Not sure why yet...investigating now.

[Scott Wells]

Hmmmmm...this is trickier than I'd have expected. A fix may not materialize for a bit just because of the chance of messing up something else in the parser. The workaround until then, of course, is to extract the assignment expression. It's still very much a parser bug that I need to address, but I need to find a really safe, isolated way to do it.

[Eric Kintzer]

Scott -- 'parser issue' - not surprising. I remember when I first posted an example of such a ternary on Salesforce Stackexchange, one of the gurus said "I didn't know you could do that (the embedded assignment)!" I understand the workaround.

[Scott Wells]

Total blast from the past, but I just committed a fix for this. The fix was both much trickier than expected and also significantly simpler than expected. Hard to explain without going into parser/grammar details, but I'm just glad this is finally addressed! The fix will be included in the next build which will likely be released Thursday morning.

[Scott Wells]

Delivered in 2.1.7.2.