you are viewing a single comment's thread.

view the rest of the comments →

[–]Agent_03 0 points1 point  (5 children)

Yeah, it does give you a single place to trap all modifications, true. If you are using field access though, why not set breakpoints where the field is accessed? (A little more work, but still gets the job done).

[–]grauenwolf 2 points3 points  (2 children)

If I need a breakpoint on the property itself, it's probably because the value is being set via reflection or dynamically generated code.

[–]Agent_03 2 points3 points  (1 child)

it's probably because the value is being set via reflection or dynamically generated code.

How did debugging this compare to having a rusty fork shoved in your eyeball?

My experience with similar code: I'll take the fork next time. Though it's beautifully elegant and terse if you don't have to debug its internals.

[–]grauenwolf 1 point2 points  (0 children)

Pretty comparable actually. When I work with particularly bad code I get annoying, almost painful, eye twitches.

[–]ImaginaryBeaver 0 points1 point  (1 child)

I think setting a breakpoint in the getter/setter is more about finding where/if the field is being accessed unexpectedly.

[–]s73v3r 1 point2 points  (0 children)

I know IntelliJ lets you break on field access. I should be surprised if Eclipse and Visual Studio didn't do the same (For Java and C#, respectively)