2

A debate has been going on at work about using Convert.ChangeType. A couple of fundamental assumptions to this discussion are delineated below:

1. The discussion is within the context of web applications.

2. The types to which I want to perform casts are primitive types.

Now, to the argument itself: would using primitive type casting such as

 if (int.TryParse(anyString, out result)) 
  {
     myObjectIntProperty = result;
  }
  else
  {
     // myObjectIntProperty = 0, default(int)
  }

be preferred over a generic approach, such as having a function like

private static  T x<T>(object o)
{
    try
    {
       return (T) Convert.ChangeType(o, typeof(T)); 
    }
    catch(Exception)
    {
       return default(T);
    }
}

?

Side A of the argument (not mine) claims that for 1.000.000 requests using int.TryParse and the likes is faster (I checked it and the difference sticks around 100 miliseconds). The claim here is "business-wise".

My side - from a developer perspective - says that giving up the generic approach is annoying, counter-productive, contradicts many principles of software engineering (reusability, functionality-unique-definition). This leaves me having to code the same checkings over and over again. What is wrong with building a infrastructure library, to provide all common required tasks throghout the project ?! Besides, I think the performance "issue" here is irrelevant to the context where the application exists.

Please, leave your comment or opinion about this. It is extremely frustrating when you have 2 mutually exclusive ideas, you think one is the correct one and you end up having to accept the adoption of the other.

  • 2
    Thing is, I only see your version of the code. What is side A's version of the code? Is the client code going to be the same? In other words: please show us the version of the code that you think is worse than your version. – jhominal May 7 '15 at 13:13
  • @gnat: it is not simply about "clean" or more elegant/modern coding, it's about the whole point of the programming paradigm of these days - maintenance. Is applying generics here "equivocally introducing overhead" ?! Having these tryParse if-else blocks all over the code, for different types, besides it being abhorrently boring and annoying (from a developer perspective, was I the CEO, I would agree that walking out with my dog means more than this developer's incomprehensible freaking out) would not be a nightmare would we need to change something in the way we deal with these validations ? – Veverke May 7 '15 at 14:00
  • These two different pieces of code have different behaviour in the invalid format case. One returns a default, the other throws. – Ben Aaronson May 7 '15 at 14:41
  • @BenAaronson: thanks for the remark, but that's not the point Ben, I am trying to find which solution cannot accomplish what the other does. What you suggested can be done in the generic scenario. I have updated it. – Veverke May 7 '15 at 14:47
  • 2
    I understand it may seem like I'm missing the point here, but it's possible that there are requirements and considerations that you're not taking into account here that are informing the other side of the argument, so it's important to dig into exactly what's needed – Ben Aaronson May 7 '15 at 15:18

Browse other questions tagged or ask your own question.