tag:blogger.com,1999:blog-6848574.post7513571316750121818..comments2024-02-14T04:44:39.043-06:00Comments on Working notes: Paulahttp://www.blogger.com/profile/03653112583629043593noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-6848574.post-25451004647294156752009-02-19T09:55:00.000-06:002009-02-19T09:55:00.000-06:00I should have explained that this is exactly what ...I should have explained that this is exactly what CAUSES the problem. If I'm not stepping through it, then the code runs correctly. My lack of explanation was most likely due to it being about 1am, and I was getting frustrated.<BR/><BR/>I had a bug that I was trying to track down (it ended up being a silly mis-reading of an API), and in the process I decided to step through the relevant code. However, some <EM>really</EM> weird things started to happen, and I finally realized it was because the state of certain objects wasn't set correctly. When I paid more careful attention, I discovered that it was being caused by an assignment statement not working. In desperation, I followed the assignment with <B>if()/throw</B> that described above, and voilá!<BR/><BR/>Once I made the post, I decided to set my breakpoints more carefully, which is how I found the problem in the end.<BR/><BR/>I didn't blog about it, but a couple of months ago I encountered a similar problem with ByteBuffers. A member variable (the "position" in the buffer) did not change, despite a relative <B>get()</B>. In this case, it happened regardless of being stepped through or running normally. In that case I fixed it by using absolute addressing instead of relative (the <B>get(int)</B> method instead of <B>get()</B>), but there wasn't such a simple fix here.Paulahttps://www.blogger.com/profile/03653112583629043593noreply@blogger.comtag:blogger.com,1999:blog-6848574.post-35962420010944961562009-02-19T03:31:00.000-06:002009-02-19T03:31:00.000-06:00Have you tried stepping through it in the debugger...Have you tried stepping through it in the debugger?Anonymousnoreply@blogger.com