Share via

Better information in error cases

  • Article

Dr. Pizza raised an interesting point in response to the previous post about method overload resolution, specifically:

“...but I would say that I hadn't realized why it didn't show completion information in some situations. Now it seems clear”

I thought this was pretty important to call out because it it exemplifies a problem that can arise when you work on a product for too long.  Namely, you start to recognize and accept the limitations of your current implementation and you don't realize that from the end users perspective something will just seem broken and they won't have any idea why.  What's worse is that often times people end up confused, suprised or thinking that they've done something wrong.

With regards to the previous post, let's look at completion lists.  A simple description of a completion list would be that is shows possible things that you would want to type given the current code context.  Note: we can't say “show all valid things that could be written at this point” as you might be writing something like a method call to something that doesn't exist.  There are also issues given the nature of code to be continuously broken as you're in the middle of typing it, and for parse trees to often be in very confusing shapes, which can cause all sorts of fun disambiguating scenarios to arise.  And, for the most part if you're typing complete gibberish we will probably to a pretty bad job of dealing with the situation.  (Just try typing your language of choice in an editor designed for another language and see how long it takes for it to get unhappy).  However, if you are writing reasonable C# code then it is certainly reasonable to expect this feature to “work” given the above intuitive definition.  And, given the extreme cases that cause completion lists to screw up, you might reasonably be unsure why things weren't working when you were typing fairly normal code.

So the question I have is “is it necessary to try and convey that information to the user” and, if so, “how?”  C++ currently just says “Intellisense: 'Type of expression to the left of the . has a type which could not be resolved'” in the status bar.  Would similar messages be useful to users, or just spam?  Something akin to “type of expression could not be evaluated because it contains an operator in it” or “unable to resolve method call to a single overload of Foo”?  I don't like the latter because it seems to imply that you've done something wrong and that when you compile you'll get a message about an ambiguous call to a method.  However, when it compiles correctly you'll probably be asking yourself “what the heck was that message talking about!?”  Of course, it's not pleasurable to think about announcing to the user: “sorry, couldn't do that because it just isn't supported”, but if it was valuable feedback and prevented users from thinking that their code was at fault, then it might be a reasonable thing to do.

Comments

  • Anonymous
    July 18, 2004
    Even though the C++ error is often wrong (as it oftentimes means that IntelliSense has just given up the ghost and needs its file deleted), and is often frustrating, it's still preferable to the behaviour that C# seems to exhibit--doing nothing at all. If nothing else, it just lets me know that the computer "heard" me but can't do anything to help me out.

    So, yes, I believe it would be useful.

  • Anonymous
    July 19, 2004
    I've often wondered why the current state of intellisense could not be communicated via the appearance of the caret - after all, that is where the coder's attention is focused (or is that just me?).

  • Anonymous
    July 19, 2004
    Daren: Could you give me an example of what you mean. How would you differentiate the cursor to convey the state of intellisense?

  • Anonymous
    July 19, 2004
    Intellisense: confused
    in the status bar

  • Anonymous
    July 19, 2004
    The comment has been removed

  • Anonymous
    July 19, 2004
    Or we could have clippy wander onscreen and do a little confusion dance.

  • Anonymous
    July 19, 2004
    Damien: Could you mock up some images of what that would look like?

    I'm getting a picture of "Filler Bunny" dancing around, but I don't think many people would get the reference.

  • Anonymous
    July 19, 2004
    Thats disgusting (I looked it up), but somehow aesthetically pleasing.

  • Anonymous
    July 19, 2004
    I think the idea of augmenting the cursor is a good one, but I think it would be more inline with current MS functionality and more easily recognized to use sub script.

    Concept:
    The cursor is augmented with a symbol in a trailing subscript that reflects the current status of intellisense.

    Definitions:
    ! : Intellisense has detected an error (syntax, etc.)
    * : Intellisense has possible suggestions
    ? : Intellisense is confused on the current code

    Considerations:
    I would put the maniputlations on about a 3 second delay. If I am actively typing I don't care what Intellisense is thinking; I am busy. If I think I've messed something up or need help, I am going to pause.

    Food for thought...

  • Anonymous
    July 19, 2004
    Another thing that I find annoying is that C++ and C# operate differently.

    I truly don't understand why the text editors aren't consistent across the different languages vs.net understands. I mean, I understand that there may be some differences; C++ is harder to parse than C# so sometimes its IntelliSense won't be able to tell you what's what; for example, its templates are generally unbounded (relying only on matching operations) so when writing a class or function template it can be hard to provide assistance.

    But I don't understand why, for example, C++ should offer a warning when it can't autocomplete but C# doesn't. Shouldn't these things be built to operate in the same way?

  • Anonymous
    July 19, 2004
    The comment has been removed

  • Anonymous
    July 20, 2004
    The comment has been removed

  • Anonymous
    July 20, 2004
    Dr.Pizza: I don't think this is unusal at all.

    I'd like to know more about your development practises involving the different languages. Fele free to send me a message through the contact link if you'd be interested in discussing this with me.

  • Anonymous
    July 20, 2004
    The comment has been removed

  • Anonymous
    July 20, 2004
    Kavan: I thought you hated VB. It had all those things like optional parameters which you didn't like!!

    :-)

    See my last post to Dr. Pizza. I'd also like to discuss this with you.

  • Anonymous
    July 20, 2004
    The comment has been removed

  • Anonymous
    July 20, 2004
    The comment has been removed

  • Anonymous
    July 20, 2004
    MikeB: We've addressed many of these issues in VS2005 and I would really like to hear if they're working for you.

    Specifically, we've added type colorization so that you can now tell instantly when intellisense cannot bind to something you've typed.

    Also, we've added a smart tag to automatically fully qualify the name or add ausing for it when this happens and its' a type that we know about in the system.

    Could you try out the beta of the express sku and tell us what you think?

    Thanks!

  • Anonymous
    July 21, 2004
    The comment has been removed

  • Anonymous
    July 21, 2004
    The comment has been removed

  • Anonymous
    July 21, 2004
    " and wouldn't ever think to discuss the "C++ editor" or the "C# editor". "

    Indeed.

    From reading blogs it's clear, however, that that's how MS is approaching things.

    IMHO that attitude needs to be rethought. It's not appropriate for a multi-language IDE.

  • Anonymous
    July 22, 2004
    David, we are looking into changing the behavior of // to be consistent between C#/C++

    Dr.Pizza: We approach it that way because VS is a platform that one can ship editors in. It is mostly language neutral. I.e. when someone plugs in something like a scheme or dylan editor we cannot enforce other language constraints on it. So instead a command like "comment out this span of text" gets sent to the individual language, since it's not safe to just insert //'s into the buffer. Each language then takes care of it according to it's own rules.

    We don't believe that it's the case that there is one right answer to how should everything behave, and while we understand the argument for consistency, it's not considered the most important thing when designing or implementing a feature.

    Also, in response to " maybe people really do want C++ to warn them when it can't IntelliSense but don't mind when C# doesn't. "

    I dont' think I ever stated that people didn't mind. I think I was asking if the C++ model was helpful and if people had other suggestions (which they have) for a better way to present this to the user.

    Note: C# is it's own product that ships seperately. It happens to be the case that it integrates within VS just like many other products out there (the exact number that do this is quite large). We coudl try to approach it as one single entity, but that would be incredibly dificult to coordinate with our ISVs with. But maybe our customers would like it more if we enforced consistency across everything.

  • Anonymous
    July 22, 2004
    "Dr.Pizza: We approach it that way because VS is a platform that one can ship editors in. It is mostly language neutral. I.e. when someone plugs in something like a scheme or dylan editor we cannot enforce other language constraints on it. So instead a command like "comment out this span of text" gets sent to the individual language, since it's not safe to just insert //'s into the buffer. Each language then takes care of it according to it's own rules."
    Sure, but there can still be a "VS way of doing things". So, for example, the behaviour of the comment tool should be to put the comments at the left margin for all languages where that's possible (I mean, I can understand breaking the rules if one had a language where it just wasn't possible to meet the rules, but that should be the exception, not the, er, rule. Apart from anything else, the deviation in behaviour in such cases is expected and understood, rather than being simple whim). Or IntelliSense should always warn if it can't help you out. And if you make the warning mechanism more interesting (by messing with the cursor, for example) it should be done across the board. Maybe this'll mean having an interface for cursor manipulation so that ISVs can tap into the same mechanism (so they all use a consistent "IntelliSense doesn't recognize the type" or "IntelliSense is confused by what you've written" or whatever cursor/wiggle underline/etc.), but if that's the price to pay, so be it.

    "We don't believe that it's the case that there is one right answer to how should everything behave, and while we understand the argument for consistency, it's not considered the most important thing when designing or implementing a feature. "
    It should be. It's surely the people spending hundreds of dollars on VS.NET that are getting the software entrenched, not the people spending $100 on Standard editions (or Express editions, as they now seem to be called).

    "Note: C# is it's own product that ships seperately. It happens to be the case that it integrates within VS just like many other products out there"
    This is why it can't be treated simply as its own product. If the only similarity between the products was that they were development environments--if they were as different as VB and VC++ 6 were--then it wouldn't matter. But they're just /not/.

    Eclipse has a similar approach, and IMO it really hurts it. It takes things further than VS.NET does (I don't know that it's actually any more /capable/ in this regard in VS.NET, rather it's just that due to its development and distribution model these things are rather more in-your-face than in VS.NET) and it suffers because of it; there are loads of plugins but they don't really work together. They don't offer consistency because they were all developed with the mindset of independence. VS.NET has taken a few steps down that path already, and I personally don't care to see it take any more. Eclipse is what I use in my day job, and I curse it every time I use it, because it feels too much like disjoint pieces of functionality, and not an integrated coherent environment.

    "(the exact number that do this is quite large). We coudl try to approach it as one single entity, but that would be incredibly dificult to coordinate with our ISVs with. But maybe our customers would like it more if we enforced consistency across everything. "
    I imagine the customers who use the single-language instantiations won't mind one way or the other (because they won't know). On the other hand, I suspect that every developer who uses multiple languages will be thankful (even if they're not really cognizant of the fact) if you do go for more consistency. It'll just feel that bit better.

  • Anonymous
    July 22, 2004
    Dr. Pizza: I've added you as a vote for consistency between langauges as something we should do in the next version. Is that ok with you?

    Also, when you say "it should be", note that that's a completely valid opinion, it's just not hte opinion we hear from everybody. Nor is it something that people (so far) have tended to find as important as other work that is done. However, it's not unimportant either. You're not the first to state this, and there have been many passionate people sending this exact feedback to us.

    It is very much being considered and will be weighed against all the other work we want to do in the feature to see if it should be done.

  • Anonymous
    July 22, 2004
    "Is that ok with you? "
    Only /a/ vote?

    I feel more strongly about it than that.

    :)

    "it's just not hte opinion we hear from everybody"
    I'd be genuinely interested about those multilanguage users who don't hold that opinion--to know their explanations and rationales.

    If they're not users of multiple languages then their opinion on the issue counts for nothing, of course.

  • Anonymous
    June 01, 2009
    PingBack from http://uniformstores.info/story.php?id=5349

  • Anonymous
    June 01, 2009
    PingBack from http://uniformstores.info/story.php?id=19338

  • Anonymous
    June 02, 2009
    PingBack from http://uniformstores.info/story.php?id=33327