I've been using Flex/Flash Builder for a couple of years now, and have only discovered something today. I was looking at some complex code which worked fine, but I needed to know how it behaved, so I placed a breakpoint in it and low and behold it threw an exception. I took it out again and it ran through OK (even with trace statements). I thought this was odd.
To cut a long story short, after a lot of head scratching it turns out that if you have a getter in your code, and during the debug process your Variables View (or Expressions View) displays the var that the getter gets, then the Flash Builder debugger will run the getter (silently) in order to calculate the value displayed in the Variables View.
In other words, under certain circumstances, by debugging your code, it may run a completely different path to how it would run if you weren't debugging (and which path it follows depends upon whether you have the Variables View open and are displaying the var's value in it).
Is this a pretty serious flaw?
I always thought that if you run an application in debug mode it should run the exact same code path that it takes when not debugging, provided the inputs are identical (although I realise it can get pretty hard to replicate real time use when debugging around event handlers for losing/gaining focus etc).
The other scary thing is that the getter is called silently by the debugger - ie if you have a breakpoint in the getter it won't stop there when the debugger calls it to update the var's value in the Variables View. So you don't even realise its running the getter.
Shouldn't the var in the Variables View just display a value of null until its getter is eventually run under the normal course of code execution?
Edit (28/7/11): My original post stated that setters were run, which is wrong - it is the getters, as described above. As such this "flaw" exists only when code in the getters performs additional functionality above and beyond the mere getting of the var value - additional functionality like this in getters is a "code smell" to me, therefore the original flaw exists, but really only in tainted code
