Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements


Blue Ink Blue Ink
  • Amazon attempting to kill Santa

    In related news, slingshot sales went through the roof.

  • The new scroogled ad...

    @wastingtimewithforums: as I said, it's not as easy as it should.

    But one readily sees that there's no trace of "outright hacking (pulling Ethernet cable)". Keep up the good work, never let facts get in the way of your prose.

  • The new scroogled ad...

    , wastingtime​withforums wrote

    Method and intent is the same as with Google+ and youtube. Yes, with enough trying or outright hacks (pulling ethernet cable) it's possible to trick W8.. does this really whitewash Microsoft? Furthermore, an OS is important, youtube comments not so much, the scope on 8.1 is thus far greater.

    It may not be as easy as it should be, but it's a lot easier than you imply.


  • Genius

    @evildictaitor: I believe the campaign is more an attempt at character assassination than a sales pitch.

    Making people realize they are "paying" for what they might have perceived as a free service may not compel them to switch, but Google's brand will have a somewhat fainter halo as a result.

  • point me to posting guidelines

    @Jason818: you can find links to the Code of Conduct and Terms of Use at the bottom of this page. The link to Common Sense is currently missing, but you can just use your own instead Smiley



  • Erik Meijer: Microsoft completely messed it up (with .NET)

    , Bass wrote


    Notice though that he said he likes checked exceptions too. You treat the exception as literally a part of the function's signature. Eg: "T MoveNext() throws EndOfCollectionException"

    Checked exceptions FORCES the developer to handle the exception in question, so they aren't going to randomly be handled somewhere up the stack by some other code. And it actually makes a ton of sense with exception constructs that are very likely to happen.

    C# does not support checked exceptions. You'd also want exceptions that aren't slow as a language feature as well. Java supports all this actually, checked exceptions, and you can make stuff that is "thrown" but not strictly an exception by deriving from Throwable.

    Really exceptions/etc. are all just a type of syntax for the more fundamental maybe construct explicitly found in some purely functional languages. Using something derived from maybe is the only way I can see to implement something like IEnumerable without introducing the side effects in question.

    Personally, I think that checked exceptions are a good thing waiting to happen. In other words, I like the idea, but I still haven't found an implementation I feel comfortable with.

    But  don't think that solves any of the problems I outlined.

    Say you have the method:

    T MoveNext() throws EOCException;

    This means that if I call MoveNext() I must also handle EOCException. So far so good and, as long as there is just one enumerator used in a given method, everything is fine. But the problem is that the only reasonable way to use MoveNext(), at this point, is to write something like this:

    try {
      while (true) {
        var item = enumerator.GetNext();
        ... // use item
    } catch (EOCException) { }

    Checked exceptions are marginally helpful here: as long as my method doesn't include a  "throws EOCException" (or one of its base classes) in its signature, I cannot possibly forget about that catch. But nothing prevents me from catching the wrong exception, for instance.

    Things get progressively worse as we go and try to use more enumerators at the same time; just think what an implementation of Zip would look like.

    With all its faults, I still think that:

    while (enumerator.MoveNext()) {
      var item = enumerator.Current;

    is saner. Even disregarding all the possible performance implications, I still have to find any situation where using exceptions to control flow provide a major advantage.

    Back to checked exceptions, they can even be dangerous. Consider the following example:

    T MoveNext () throws EOCException {
      if (moreitems) {
        return nextItem;
      } else {
        throw new EOCException();

    What happens if Foo() throws an EOCException? The caller cannot possibly distinguish between an exception that signals the end of the enumeration from one that signals... what exactly?

    Ok, so it's the fault of the programmer for not looking up the signature of Foo(). But it may well happen that Foo(), when our MoveNext was written, didn't actually throw. Later on, the code for Foo was changed, and its signature now includes "throws EOCException".

    Our code still compiles, but the semantics now have a nasty bug.

    Again, all of this can be mitigated and probably solved by making enumerators special for the compiler, but that means we have to devise new language features.

  • Erik Meijer: Microsoft completely messed it up (with .NET)

    @androidi: In C++, exceptions are relatively inexpensive, but that's pretty irrelevant: IMO exceptions were designed to handle exceptional conditions (duh), and hitting the end of a collection is not exceptional at all as you do expect it to happen, eventually (unless you are enumerating a collection that can be considered infinite for all practical purposes, of course).

    For an example of why I think this is not a good idea, see what would happen if, as Erik seems to suggest, IEnumerable just had a MoveNext() that either returns the next element in the collection or throws if it reached the last element (say it throws an EndOfCollectionException).

    Sounds good, until we realize that we have to make sure that nothing can throw an EndOfCollectionException outside of a call to MoveNext(), and that every EndOfCollectionException must be caught by the caller of the MoveNext() method that threw it. Failure to do so would allow "rogue" exceptions to bubble up in the wrong place and cause all kinds of bugs.

    I don't know of any reasonable way to implement this except by making it a special case that the compiler has to handle; in a nutshell, we would be creating a new language feature for flow control that looks like exception handling.

  • XBox One Kinect

    @cbae: if that's the rule, everybody who didn't buy the game will eventually get the achievement. Smiley

  • A generic wrapper class for enum flag types?

    @BitFlipper: the problem with your implementation is that while you correctly check that it's an Enum type, you don't check if it has the FlagsAttribute. Without that check, the logic is easily broken.

    To be fair, that's exactly the same issue you get with regular enums, but at that point I wonder if it makes sense to pay for all the reflection and boxing.

    The bottom line is that if you are not concerned with performance, I would suggest you use a HashSet<T>, which provides lots of power (at a price); otherwise, you could just go with some convenience extension methods of the "use at your own risk" variety.

  • Kinect is getting there

    I always thought that a good benchmark for the Kinect would be the ability to translate from sign languages, at least partially.

    That was a tall order, but apparently the Kinect is a lot better than I thought. Good job MSR, that's amazing.