NPE during syntax highlighting due to null evaluated expression type

[Scott Wells]

This was reported by a user, manifesting as an issue with syntax highlighting in a file after a certain point. Based on the provided idea.log it appears that some declaration’s evaluated expression type is null (which may well indicate a lower-level issue), so minimally need to be properly defensive against that possibility. Then we can see why a declaration is evaluating to no expression type.

Using this issue both to track the bug and its fix, but also to provide a test build (potentially several if needed) to the user to help confirm the fix(es).

[Scott Wells]

This is a build of 2.3.1.5 with a prospective fix for the observed issue. To install it, download (but don't extract) the attached plugin archive, then use Settings | Plugins | Install plugin from disk (under the gear drop-down menu) and allow the IDE to restart.

[Atanas Vasilev]

I just installed the attached build and can confirm that the issue is not manifested.

Also, the issue is not manifested with 2.3.1.4
It is manifested with the officially released 2.3.1.5

[Scott Wells]

Okay, that’s good to hear. Do you see any other odd behavior now that the original errant behavior is resolved?

[Atanas Vasilev]

Not sure if this is expected behaviour, but I just renamed an exceptoin type to a value not matching any of the project exception types and it was not highlighted as an unknown type. I just added an extra 'n' to the expected exception type.

‌

[Scott Wells]

There should not be any false positives from the unresolved declaration code inspection. If those member references are in fact valid/resolvable and are showing up as unresolved, that wouldn’t be expected/correct. Can you please send another log for review, either here or via email?

[Atanas Vasilev]

Log is on its way via email

[Atanas Vasilev]

It just seems weird that I’ve referenced a non-existing exception type and it is not highlighted as an unknown type, plus there’s a green check near the top-righ corner with a 'No problems found' tooltip.

[Scott Wells]

Oh, I totally agree. Unfortunately with no exceptions/errors in the provided log, it’s difficult to determine what might be happening. As mentioned in the direct email response, it would be useful if you could provide reliable steps to reproduce, ideally in an environment that can be replicated external to any proprietary project files. That way I could see the same behavior locally and track down why it’s happening.

[Atanas Vasilev]

Unfortunately this behaves as expected in a brand new, isolated class.

‌

[Scott Wells]

Not surprising. If you get a chance – and even want to – see if you can come up with a (relatively) standalone reproduction and provide that. Doesn’t have to be now…could be if/when you run into this again in the future. Minimally it looks like the main issue you were seeing should be resolved. Feel free to stay on the attached build for the moment, and the actual fix will be included in Thursday’s official build.

[Atanas Vasilev]

Sure, will provide a zipped isolated project if I’m able to reproduce it. Strange thing is that right now I just copied (Refactor/Copy) the class that referenced this unknown exception type, without changing a single character and in the newly spawned tab this was properly highlighted with 3 errors. Not sure why the first two are identical, but still:

‌

[Scott Wells]

That would generally mean that the index that IC2 uses for type inheritance relationships is in a (temporary) bad state and it’s not seeing DeactivatedRecordExceptionn as extending Exception. How did you rename that type?

[Atanas Vasilev]

In the original class I just appended an ‘n' to ‘DeactivatedRecordException’.
Then after I copied the original class via Refactor/Copy, a new tab was displayed with the 'Cannot resolve… ’ errors already highlighted

[Scott Wells]

Just so I understand completely, you manually added an n t othe end of the class name, both in its declaration and in its usage? Or only in the usage such that it should technically be an unresolvable type in the catch block?

[Atanas Vasilev]

I appended an ‘n' just in the usage, as I was expecting for this to result in an error.
Had I refactored the DeactivatedRecordException by renaming it, I wouldn’t expect for a 'Cannot resolve… ' error to be highlighted.

[Scott Wells]

Got it. Yeah, I would expect the exception type to be flagged as unresolving and not assignable to Exception, and all attempts to resolve from the exception variable to be similarly flagged. And that’s what I’m seeing locally:

‌

It’s definitely odd that you’re not seeing the same. Does it happen everywhere or just in that specific source file?

[Atanas Vasilev]

Just this specific file that I uploaded originally via email near the beginning of today’s exchange.

• When I created a minimalistic example shared in this comment this was highlighted properly
• When I copied the original class via Refactor/copy, the resulting tab contained properly highlighted 'Cannot resolve symbol…' errors

And to rule out bad/broken caches I’ve invalidated caches and restarted twice before reporting this secondary issue.

‌

[Scott Wells]

Yeah, that doesn’t sound like a bad index/cache but rather the code inspection pass just not getting to that particular exception variable declaration to mark it as unresolvable (the IDE has a safeguard to cancel and reschedule inspection/syntax highlighter, etc., processes). Does it eventually highlight properly if you keep editing the file, or does it never highlight? How large is that specific class? Is it the same one you shared previously?

[Atanas Vasilev]

If I continue editing for example adding a line with a syntax error, the newly fabricated error is properly highlighted, but the unresolved exception type still isn’t.

Yes this is the same class that I originally sent via email, but I’ll re-send it again, as I’m not sure if the exception handling I added before- or after I sent the class file to you.

‌

[Scott Wells]

Delivered in 2.3.1.6.