False negative inspector for ternaries
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...
Comments (6)
-
repo owner -
repo owner Yep, that's what's going on. For some reason the parser is thinking that
transactionId
intransactionId = String.valueOf(...)
is the beginning of a reference expression instead of an assignment expression. Not sure why yet...investigating now. -
repo owner 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.
-
reporter 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.
-
repo owner 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.
-
repo owner - changed status to resolved
Delivered in 2.1.7.2.
- Log in to comment
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.