Debugging exception in ProblemDescriptorImpl

Hi

In my inspection, LocalInspectionTool.checkMethod() gets called and I extract the method's parameters from the parameter list. If needed, the parameter (not null) gets passed on to InspectionManager.createProblemDescriptor(). One user has reported the exception below.

Could someone from JB please tell me what assertion failed? That would be great! Thanks in advance.

--Etienne


at com.intellij.openapi.diagnostic.Logger.assertTrue(Logger.java:78)
at com.intellij.openapi.diagnostic.Logger.assertTrue(Logger.java:86)
at com.intellij.codeInspection.ex.ProblemDescriptorImpl.]]>(ProblemDescriptorImpl.java:18)
at
com.intellij.codeInspection.ex.InspectionManagerEx.createProblemDescriptor(InspectionManagerEx.java:91)

5 comments

Hello etienne,

The element passed to ProblemDescriptor is either invalid (most probably
cached somewhere and then passed to after it have been deleted or reparse
had happened) or non-physical, i.e. comes not from real file but created
by means of PsiElementFactory.

-


Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Hi

In my inspection, LocalInspectionTool.checkMethod() gets called and I
extract the method's parameters from the parameter list. If needed,
the parameter (not null) gets passed on to
InspectionManager.createProblemDescriptor(). One user has reported the
exception below.

Could someone from JB please tell me what assertion failed? That would
be great! Thanks in advance.

--Etienne

at com.intellij.openapi.diagnostic.Logger.assertTrue(Logger.java:78)

at com.intellij.openapi.diagnostic.Logger.assertTrue(Logger.java:86)

at
com.intellij.codeInspection.ex.ProblemDescriptorImpl.<init>(ProblemDes
criptorImpl.java:18)

at

com.intellij.codeInspection.ex.InspectionManagerEx.createProblemDescri
ptor(InspectionManagerEx.java:91)



0

Maxim,

wouldn't this be the perfect use case for the new Structural Search based
Inspections?

$LOG$.assertTrue($EXPR$)

QuickFix:

$LOG$.assertTrue($EXPR$, "$EXPR$)

This could make the life for plugin developers so much easier :)

Sascha

0

Hello Sascha,

We've already added proper message for this particular one. I like your idea
but will "element.isPhysical()" message be much of help?

-


Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Maxim,

wouldn't this be the perfect use case for the new Structural Search
based Inspections?

$LOG$.assertTrue($EXPR$)

QuickFix:

$LOG$.assertTrue($EXPR$, "$EXPR$)

This could make the life for plugin developers so much easier :)

Sascha



0

Hello Maxim,

We've already added proper message for this particular one. I like your
idea but will "element.isPhysical()" message be much of help?


It's certainly more helpful than without any message ;)

Seriously, it depends on the experience of the plugin writer if such a message
is of any use, but at least for the standard cases like isValid(), isPhysical(),
not null, etc. this should provide enough information to get a rough idea about
what's wrong.

Of course that shouldn't stop anyone to write more detailed assert messages, but
it would be quite a good and (probably) easy to accomplish start :)

Sascha

0

Hi Maxim

Thank you very much for the quick help! I now check for isValid() and isPhysical() in my code.

I agree with Sascha that a little message for the assertion could be helpful, and maybe cause less support issues for you guys ;)

--Etienne

0

Please sign in to leave a comment.