Recursive #printOn: renders the image unusable
Today I made the mistake (twice) of developing in the debugger a #printOn: method depending on a not yet defined #name method in the same class. The result is an image completely blocked out, with an infinite recursion trying to print receiver The culprit is Object>>#name, which by default... is the receiver printString (bypassing the #printStringLimitedTo:... version)! So if you implement #printOn: depending on #name, but you didn't implement #name differently to how Object does, you created yourself an infinite recursion. Now I found why it is happening, so I will explicitly define #name prior to any #printOn: implementation. Particularly if I'm inside the debugger which will try to print the offending class or any variable affected by this bug. However I have a few questions about this: a) Shouldn't a recursion too deep be detected? b) Why can't I interrupt a process running in the UI thread like this one? Regards. Esteban A. Maringolo The call stack: DTColumnParameter(Object)>>printOn: DTColumnParameter>>printOn: DTColumnParameter(Object)>>printStringLimitedTo: in Block: [ :s | self printOn: s ] String class(SequenceableCollection class)>>streamContents:limitedTo: DTColumnParameter(Object)>>printStringLimitedTo: DTColumnParameter(Object)>>printString DTColumnParameter(Object)>>name <<---- Here we go... DTColumnParameter>>printOn: DTColumnParameter(Object)>>printStringLimitedTo: in Block: [ :s | self printOn: s ] String class(SequenceableCollection class)>>streamContents:limitedTo: DTColumnParameter(Object)>>printStringLimitedTo: DTColumnParameter(Object)>>printString DTColumnParameter(Object)>>name
Hi all, for what itâs worth, I actually would prefer Object>>name to be removed. It does not make sense to me to be defined at that level, and whenever I define an Object subclass with a name instvar and accessors, I am surprised (luckily no longer worried) when I see that I am overriding name. On Sep 15, 2014, at 8:48 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Today I made the mistake (twice) of developing in the debugger a #printOn: method depending on a not yet defined #name method in the same class.
The result is an image completely blocked out, with an infinite recursion trying to print receiver
The culprit is Object>>#name, which by default... is the receiver printString (bypassing the #printStringLimitedTo:... version)!
So if you implement #printOn: depending on #name, but you didn't implement #name differently to how Object does, you created yourself an infinite recursion.
Now I found why it is happening, so I will explicitly define #name prior to any #printOn: implementation. Particularly if I'm inside the debugger which will try to print the offending class or any variable affected by this bug.
However I have a few questions about this:
a) Shouldn't a recursion too deep be detected? b) Why can't I interrupt a process running in the UI thread like this one?
Regards.
Esteban A. Maringolo
The call stack:
DTColumnParameter(Object)>>printOn: DTColumnParameter>>printOn: DTColumnParameter(Object)>>printStringLimitedTo: in Block: [ :s | self printOn: s ] String class(SequenceableCollection class)>>streamContents:limitedTo: DTColumnParameter(Object)>>printStringLimitedTo: DTColumnParameter(Object)>>printString DTColumnParameter(Object)>>name <<---- Here we go... DTColumnParameter>>printOn: DTColumnParameter(Object)>>printStringLimitedTo: in Block: [ :s | self printOn: s ] String class(SequenceableCollection class)>>streamContents:limitedTo: DTColumnParameter(Object)>>printStringLimitedTo: DTColumnParameter(Object)>>printString DTColumnParameter(Object)>>name
---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
participants (2)
-
Esteban A. Maringolo -
Johan Fabry