Whidbey Readiness Quiz (Answer): Converting array values


Well, lots of good responses I can see this is going to be a hard group to stump.  Nat nailed all the points quickly, even if it took him two posts to do it ;-)… there were several other great responses as well. 

 

 

Here is the code I came up with… I wanted to high light three things:

  1. The “funcational” methods on Array… You can do some neat stuff with ConvertAll, ForEach and friends with C# new annonoums method support… give them a whirle and see what cool thigs you can come up with.
  2. TryParse()… It allows you to avoid catching and eating exceptions… bad programming practices and bad perf.  If you find your self doing anything like this today you will love TryParse:
      int i;

        try

        {

            i = Int32.Parse(“42”);

        }

        catch (FormatException)

        {

            i = -1;

        }

  1. Of couse, I have to plug a bit of Color console… you can’t do a reasonable whidbey CLR demo without it 😉 

 

using System;

class Program

{

    static void Main(string[] args)

    {

        string[] inputValues = { “0”, “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “10”, “bad value” };

        int[] outputValues;

        outputValues = Array.ConvertAll<string, int>(inputValues, delegate(string value)

        {

            int i;

            if (!Int32.TryParse(value, out i)) return -1;

            return i;

        });

        Array.ForEach<int>(outputValues, delegate(int value)

        {

            if (value % 2 == 0) Console.ForegroundColor = ConsoleColor.Red;

            else Console.ForegroundColor = ConsoleColor.White;

            Console.Write(value + “,”);

        });

        Console.ReadLine();

    }

}

Comments (8)

  1. Hi, looks nice…

    But why not make a Converter class instead of a delegate as input parameter for the ConvertAll method in the framework?

    I think this approach with callbacks, method calls is more method oriented (function oriented) than Object Oriented. What’s your thought about it?

    Best,

    Johan

  2. I believe VB2005 does not have anonymous methods. Taking that into consideration, then, one would have to instantiate a delegate to pass into ConvertAll method. Is that correct? Is there anything like or similiar to anonymous methods in VB2005?
    <br>
    <br>Thanks.

  3. Jason says:

    Yeah, that’s great and all… but I think you are sacrificing readability just to use new functionality in the language.

    I realize that this is just an exercise, but I would not be happy seeing this code in any of my development team’s projects.

  4. jaybaz [MS] says:

    While you’re plugging the ConsoleColor stuff, can you explain why it’s not a tested type? (Console.Color)?

  5. Mike Dunn says:

    I’m with Jason. Sticking whole functions in the middle of other code is the opposite of readability. Using such a style in sample code will only encourage its use in "real" code, which would be Bad.

  6. Kit George [msft] says:

    JayBaz, we typcially don’t nest types in the base classes. It tends to hurt usability of the type for consumers, so we prefer keeping everything at the top level. The only time we tend to nest in the BCL is when the type is internal, so you never end up seeing it anway.

  7. Mehfuz Hossain (mehfuz@gmail.com ) says:

    TryParse is indeed a good feature,only when i want dont just care about what cause the exception.

    In a typical progam some can write;

    int i;

    Int32.TryParse(value, out i);

    area = width * i;

    Area : 0

    Then will it be possible to find what really cause the error

  8. TryParse is a good edition but I think it would be more usefull as,

    int i = Int32.TryParse(value, defaultValue);

    as the majority of times when TryParse fails you want to return a default anyway. Also, what about the ability to catch mutliple exceptions on the 1 line as,

    try

    {

    }

    catch (FormatException, ArgumentException)

    {

    }