Breakpoint for writers/readers

[Joachim Tuchel]

Hi there,

one thing I've been wondering for quite a while is if there is such a thing as a breakpoint for direct access to an instance or class variable.

From time to time I wonder why a variable is changed or who modifies it and I'd like to add a breakpoint "onto" the variable so that the debugger stops at the place that modifies (or reads) a value directly instead of using getters/setters.

Is there something I should definitely know but don't?

Joachim

[thomas....@natural-software.eu]

Hello Joachim

You can use the markReadyOnly: function for this.

Example:

[
TrsPerson new
markReadOnly: true;
firstName: 'John'.
] when: ExError do: [ :sig |
sig inspect.
sig exitWith: nil.
]

In this case an exception will be thrown with the execution of "firstName:". To handle this, just send "markReadOnly: false" to the object and "really" set the instance variable.

--Thomas

[Joachim Tuchel]

Thomas,

that's a good idea indeed. Thanks for the pointer (I wasn't even aware that you can markReadOnly: in VAST).

It works like a charm, but sometimes it will throw exceptions a lot more often than you'd wish, because it affects every variable of an object. In my case, it is an object with more than a dozen variables and one of the things that happen during the suspected malfunction is the object being matrialized form the databse (using instVarAt:put:).

I'll have to play with the exception a little and see if it uncovers enough info to skip all that I'm not interested in. 

I was hoping there is something as easy as a breakpoint that can be added by clicking on a variable name in the Class definition or such...

Joachim

[Richard Sargent]

On Thursday, August 17, 2023 at 10:09:29 PM UTC-7 Joachim Tuchel wrote:

Thomas,

that's a good idea indeed. Thanks for the pointer (I wasn't even aware that you can markReadOnly: in VAST).

It works like a charm, but sometimes it will throw exceptions a lot more often than you'd wish, because it affects every variable of an object. In my case, it is an object with more than a dozen variables and one of the things that happen during the suspected malfunction is the object being matrialized form the databse (using instVarAt:put:).

Subclass the attemptedROMStore: storedObject intoSlot: anInteger method in your target class.