detect infinite recursion

could a plugin do this?
I think it should be possible at least for simple cases:

when a method calls itself and has no (other) exit points
it's an infinite recursion.
And IDEA is able to parse exit points, as I can see when
extract-method fails because of "multiple exit points".

IDEA could highlight sth. like this just as it does
for "silly assignment".

6 comments
Comment actions Permalink

In general, no, as this is a subset of the halting problem. In certain specific cases (like the one you mention), this could be automated as an inspection. If you'd like, I'll put it on the TODO list for the InspectionGadgets plugin. Otherwise, you can submit it as a tracker request.

--Dave "Always looking for new inspections" Griffith

0
Comment actions Permalink

a TODO for the InspectionGadgets would be fine ;)

0
Comment actions Permalink


"Dave Griffith" <dave.griffith@cnn.com> skrev i en meddelelse
news:14764831.1065875306348.JavaMail.itn@is.intellij.net...

In general, no, as this is a subset of the halting problem. In certain

specific cases (like the one you mention), this could be automated as an
inspection. If you'd like, I'll put it on the TODO list for the
InspectionGadgets plugin. Otherwise, you can submit it as a tracker
request.
>

--Dave "Always looking for new inspections" Griffith


Well, if you like - it's your plugin.
But I think this will catch very few errors "in the wild" - detectable
infinite recursion is likely to be very unusual.

However, an inspection to detect "infinite" loops - that is, loops that are
only exited by throwing an exception wold be useful. While these can be
legitimate, they are most likely just a symptom of poor coding.

You could look at some of the commercial tools (e.g. teamstudio) for
inspiration.
TeamStudio have a list of their inspections at
http://www.teamstudio.com/tsv3/teamstudio.nsf/pages/6372B8EE864C42AE85256CCC0053977A?opendocument&cc=us

Some of these (e.g "ThreadDeath not rethrown" and
"Definition of main other than public static void main(java.lang.String[])")
would be relevant as well.

For fun, you could tackle inspections that would detect the errors in Bloch
& Gafters "Programming Puzzlers"
http://www.sfbayacm.org/speaker-presentations/puzzlers.ppt
and "More Programming Puzzlers"

(http://www.java.no/web/moter/javazone03/presentations/JoshuaBloch_NealGafte
r/Puzzlers.pdf)"

Some of these should be quite easy to detect - (I won't give spoilers here).

Niels Harremoës




0
Comment actions Permalink


Actually, I had a couple the other day this would have caught. They happened during a refactoring, when I found I had dropped the "super" on a call to a parent's method. Little cases are probably the most likely bugs to be caught by this, not big logical errors.

I did look at TeamStudio (and JTest, and CheckStyle, and CodeCoach, and, and) for inspection possibilities, and have implemented most of the ones I found there (including "ThreadDeath not rethrown" and "Confusing main method", already in the plugin).

Loops exitable only by throwing exceptions are a worthwhile addition. While most cases of this are already caught by the compiler (if there is a statement after such a loop, it's unreachable, and thus a compile-time error), the remainder are worth catching. Thanks for catching that one.

0
Comment actions Permalink

Probably wasn't your fault, most likely related to this blooper:
http://www.intellij.net/tracker/idea/viewSCR?publicId=16615

N.

Dave Griffith wrote:

Actually, I had a couple the other day this would have caught. They happened during a refactoring, when I found I had dropped the "super" on a call to a parent's method.


0
Comment actions Permalink

Yup, that's the one.

0

Please sign in to leave a comment.