Detecting recursion loops

[robert]

Neil Cerutti wrote:
> On 2006-12-01, robert <no-spam at no-spam-no-spam.invalid> wrote:
>> Ben Finney wrote:
>>> robert <no-spam at no-spam-no-spam.invalid> writes:
>>>
>>>> Carl Banks wrote:
>>>>> 2. Consider whether you're unwittingly trying to cover up a bug.
>>>>> ISTM no matter how problematic the input is, you should at least
>>>>> be able to make progress on it.  Are you getting this error
>>>>> because, say, you're not incrementing a counter somewhere, and
>>>>> thus recalling a function with the same arguments again?
>>>> the "bug" comes in from the I/O input.
>>> If a program doesn't gracefully deal with bad input, that's a bug in
>>> the program. You should be designing your input handler so that it
>>> will do something helpful (even if that's to stop immediately with an
>>> informative error message) in the event of bad input, rather than
>>> allowing that bad data to send your program into an endless loop.
>>
>> Yet that detection is what the asked alg should do. Example:
>> When a HTML-(content)-relaying sends you around in a circle
>> through a complex handler chain.
> 
> Being in a cycle doesn't actually prove your program will never
> halt for that particular input, does it?

not. but its not about a theoretical prove. in practice with same state it goes through the same function here.. I had simply had situations where a server looped my client on to a Python (long through a couple of func-calls) recursion error .

thus, either I fiddle a recursion/counter parameter through my calls, or I do complex state detection as e.g. to copy that of cherrypy was recommend in other post.
Or: I simply throw a hammer at an n-th recursion, wereby I programm the counter locally  as simple counter in a "global" thread-local-storage as I wrote.(also possible to use the same counter/limit in multiple functions!) 
There were just 2 lines of code to add.


Robert