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".

0
Avatar
Permanently deleted user

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
Avatar
Permanently deleted user

a TODO for the InspectionGadgets would be fine ;)

0
Avatar
Permanently deleted user


"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
Avatar
Permanently deleted user


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
Avatar
Permanently deleted user

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
Avatar
Permanently deleted user

Yup, that's the one.

0

请先登录再写评论。