 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / March 2008Why does tsSource[j].Text.ToUpper() causes side effects
I get the following watch message: tsSource[j].Text.ToUpper() This expression causes side effects and will not be evaluated string The Text is &Edit Do you know what are the side effects? Thanks >I get the following watch message: > [quoted text clipped - 4 lines] > >Do you know what are the side effects? There probably aren't any in this case, but the debugger is not smart enough to be able to tell - so it prefers to err on the safe side. Quoting from http://msdn2.microsoft.com/en-us/library/a7a250bs.aspx : "A side effect occurs when evaluating an expression changes the value of data in your application. Side effects are something to watch for if you are evaluating expressions in the debugger. If you evaluate an expression in the Watch window or the QuickWatch dialog box and the expression has side effects, you might change the value of variables in another part of your program without realizing it. Side effects can make debugging more difficult by creating the appearance of bugs where none exist or masking the appearance of real bugs. One common cause of side effects is evaluating a function call in a debugger window. Such evaluations are usually noticeable. A more subtle cause of side effects is the evaluation of properties and other implicit function calls in managed code. The debugger cannot tell whether a property evaluation or implicit function call has side effects. Therefore, by default, the debugger does not evaluate implicit function calls automatically. Property evaluation is allowed by default, but can be turned off in the Options dialog box. When a function call or property has not been evaluated, a refresh icon appears. You can manually evaluate the expression by clicking the refresh icon. For details, see How to: Refresh Watch Values." Regards, Gilles. Thanks for the help >>I get the following watch message: >> [quoted text clipped - 49 lines] > Regards, > Gilles. > I get the following watch message: > [quoted text clipped - 4 lines] > > Do you know what are the side effects? If the type of the Text property is actually String (and that seems like a safe assumption, given your post), then there should not be any side-effects. Do you only get that message with the full expression? That is, using "tsSource[j]" or "tsSource[j].Text" works okay (other than not converting the string to uppercase, of course)? Seems like the debugger's being overly cautious to me, though why that would be, I don't know. I can't reproduce the message here with a simple call to ToUpper() in the watch window on an arbitrarily chosen string value in a test program. It seems to me that your best bet would be to create and post a concise-but-complete sample of code that reliably demonstrates the problem. Also, be sure to provide specifics regarding which version of VS you're using, and maybe even which .NET version you're using. Pete Without the ToUpper() I get no message. Thanks for the answer >> I get the following watch message: >> [quoted text clipped - 24 lines] > > Pete > I get the following watch message: > > tsSource[j].Text.ToUpper() This expression causes side effects and > will not be evaluated string I rather suspect the message is "This expression causes no side effects". What you've asked for is: Find the jth item. Read it's Text property. Make an uppercase copy. Throw away the result. >> I get the following watch message: >> [quoted text clipped - 8 lines] > Make an uppercase copy. > Throw away the result. "Watch message" implies debugger. What you're describing would be a problem if the compiler were looking at the expression, but here the result of the expression isn't thrown away, it's (in theory) displayed to the user. In practice, it seems that it's not being displayed, because the debugger believes it causes side-effects and thus won't evaluate it. Why that should be, I don't know...I can't reproduce the same problem (my debugger seems perfectly happy to put a call to ToUpper() in the watch window, even when the source is some variable or property). But it's not hard to believe that the debugger is hesitate to call a method in the watch window because of the possibility of a side-effect. Pete >>> I get the following watch message: >>> [quoted text clipped - 12 lines] > result of the expression isn't thrown away, it's (in theory) > displayed to the user. You're right. I didn't connect "watch message" with the debugger watch window. > In practice, it seems that it's not being displayed, because the > debugger believes it causes side-effects and thus won't evaluate it. Why [quoted text clipped - 4 lines] > method in the watch window because of the possibility of a > side-effect. It will display, it typically won't update without being asked, though. There are calls to an indexer, property get accessor, and method in that expression, which could be too much for the debugger to analyze. > Pete > [...] >> In practice, it seems that it's not being displayed, because the [quoted text clipped - 8 lines] > > It will display, it typically won't update without being asked, though. Right. But the OP apparently can't even get it to display. > There are calls to an indexer, property get accessor, and method in that > expression, which could be too much for the debugger to analyze. The OP says that as long as he removes the call to ToUpper(), the debugger stops complaining. An indexer and a property are, ultimately, just methods. So why does the addition of the third method cause an issue? Pete >> [...] >>> In practice, it seems that it's not being displayed, because the [quoted text clipped - 19 lines] > ultimately, just methods. So why does the addition of the third > method cause an issue? Apparently the debugger assumes that property access (including indexed properties) has no side effects, and method access does. Without attributes to give it a hint or full analysis of the code I don't see how it could do better. The real problem is that this assumption is violated in a rather big way by some BCL classes. Ever got an InvalidOperationException on Control.BeginInvoke because the handle wasn't created? Well, the handle wasn't created when the exception occured, but it is now because the debugger happily read the .Handle property. The fact that reading the Handle property creates the handle, but the CreateControl method doesn't (if Visible is false) is just really poor design in my opinion. Add to that the fact that the short description which appears in intellisense is "Forces the creation of the control, including the creation of the handle and any child controls" and you have to pull up MSDN to learn about the Visible condition, and it's a real problem. > Pete >> The OP says that as long as he removes the call to ToUpper(), the >> debugger stops complaining. An indexer and a property are, [quoted text clipped - 3 lines] > Apparently the debugger assumes that property access (including indexed > properties) has no side effects, and method access does. Apparently. But why on his computer, but not mine? > Without attributes > to give it a hint or full analysis of the code I don't see how it could > do > better. I'm not convinced the debugger should be in the business of making these decisions anyway. At most, it should warn the user that the evaluation of an expression in the watch window could have a side-effect, and since this is in reality a possibility with _any_ expression not defined solely in terms of things implemented by the debugger itself, I'm not convinced that putting up a warning on a regular basis would make sense. > The real problem is that this assumption is violated in a rather big way > by > some BCL classes. [...] I don't disagree with your complaint, but I'm not sure how it's relevant to the question of why the OP's installation is complaining about side-effects when mine is not. Pete Hello Peter, >>> The OP says that as long as he removes the call to ToUpper(), the >>> debugger stops complaining. An indexer and a property are, [quoted text clipped - 26 lines] > relevant to the question of why the OP's installation is complaining > about side-effects when mine is not. There's an attribute to mark a property debugger invisible, or to mark both a method or a property dangarous when it's being put into teh watch window. And yes, the language guidelines say that a property shouldn't have side effects while a method can. -- Jesse Houwing jesse.houwing at sogeti.nl > [...] >> I don't disagree with your complaint, but I'm not sure how it's [quoted text clipped - 4 lines] > both a method or a property dangarous when it's being put into teh watch > window. In what way is that relevant to the original question? > And yes, the language guidelines say that a property shouldn't have side > effects while a method can. And for good reason. So? How is that relevant here? Pete Hello Peter, >> [...] >> [quoted text clipped - 12 lines] >> > And for good reason. So? How is that relevant here? just addign a bit of information on where the discussion went to. Not every reply has to lead back to the OP... -- Jesse Houwing jesse.houwing at sogeti.nl > just addign a bit of information on where the discussion went to. Not > every reply has to lead back to the OP... Well, it'd be nice if you put that added "bit of information" somewhere other than a direct reply to my own post, quoting my text. When you do that, you imply that what you wrote had something to do with what I wrote, especially when you're replying to a specific question I asked. Pete >> [...] >>> I don't disagree with your complaint, but I'm not sure how it's [quoted text clipped - 11 lines] > > And for good reason. So? How is that relevant here? That if the guidelines were followed, there would be a string.AsUpper property, instead of a ToUpper() method, and the debugger would be doing the right thing. > Pete > [...] >>> And yes, the language guidelines say that a property shouldn't have [quoted text clipped - 6 lines] > the > right thing. Are you sure the debugger "would be doing the right thing"? After all, the point here -- which has been the point since the outset and which you and Jesse both seem to keep ignoring -- is that the debugger _does_ do the "right thing" on my computer. You guys keep talking about this as if it's a .NET issue, as if there's something about the API that prevents the debugger from doing the right thing. But obviously there's not. I'm using the same .NET everyone else is, but my debugger doesn't complain when I call ToUpper(). Pete >> [...] >>>> And yes, the language guidelines say that a property shouldn't have [quoted text clipped - 17 lines] > everyone else is, but my debugger doesn't complain when I call > ToUpper(). Are you? The OP didn't even mention what version of .NET and Visual Studio, so unless you tested all of them, I don't know how you can make that claim. > Pete > [...] >> You guys keep talking about this as if it's a .NET issue, as if [quoted text clipped - 7 lines] > so unless you tested all of them, I don't know how you can make that > claim. I've tried it on 2005 and 2008, in .NET 2.0 and (for VS 2008) 3.0 and 3.5 projects. I did specifically ask the OP to give us more details as to versions, but I've seen nothing at all to suggest that this could be due to some difference between .NET versions. No doubt _something_ is different, but I find all this discussion about methods vs. properties to be tangential to the real question. Of course, frankly at this point given the fact that the OP has not bothered to involve himself with the thread since posting the original question, I question the value in even pursuing the question. If he doesn't care, why should we? But more importantly, I'm trying to understand why this isn't something I can reproduce on my own computer. Maybe I just don't understand the steps I need to take, maybe it's something else. But either way I don't see how lecturing on the question of .NET API design is helping me toward that goal. Pete Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.