#subclassResponsibility (was Re: [squeak-dev] Everyone's talking about debuggers these days)

Frank Shearar frank.shearar at gmail.com
Sun Jan 27 00:00:42 UTC 2013


On 25 January 2013 22:29, Casey Ransberger <casey.obrien.r at gmail.com> wrote:
> Inline, briefly.
>
> On Jan 25, 2013, at 1:55 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
>
>> By "stub out stuff" do you mean "write a stub test case with self
>> assert: false"? *raises hand*
>
> Actually, I do that when I'm feeling responsible, as in I-might-want-to-use-this-more-than-once. More often though, I'm dinking around on Project Euler and plan to throw my code away, in which case I just paste in "self break."
>
>> Annoyingly, defining a #subclassResponsibility method destroys my
>> flow: the debugger won't, obviously, prompt you for that "create
>> method" button I love so much. (Hm, could one restore that with a
>> SubclassResponsibilityException that the debugger can catch?)
>
> I'm not sure what the right way to do that would be, but I feel your pain. Try it?

So actually the UI part is really easy, thanks to Debugger >>
#buildNotifierWith:label:message:. I now have a nice Create button, it
calls the correct method... but I'm a bit stumped. I can record in the
call of "self subclassResponsibility" the class and selector that
needs implementing (stored in a SubclassResponsibilityError), and this
causes the debugger to pop up... but I don't know how to get a handle
on the SubclassResponsibilityError itself to find out what to do.

Any ideas? (I've scratched around a fair bit with exception handling
and the Debugger, but this is one step beyond me right now.)

frank


More information about the Squeak-dev mailing list