views:

233

answers:

7

I have a asp:BoundColumn with DateTime? data (i'll call it column X) in the asp:GridView. I loop through all the rows in the grid, and cast the .Text property to column X to DateTime (i need this to do some checking and change the cell background color if needed).

I have 2 options:

  1. wrap the cast in try/catch ... handle FormatException (in case column X gets rendered with some junk in it) ... and work only with valid DateTime values.

  2. check the column X to make sure it's in the correct format (how?) before casing, and only cast if format is ok.

Which approach should i take, and why?

Thank you.

p.s. 1 up-vote for all explanations, accepted answer for TryParse

Edit2: even though i used TryParse, I've unchecked the accepted answer to keep the discussion going.

My "good data"/"bad data" ratio is about 2/1 - this means lots of bad input

I'll re-accept the answer in a couple of days, if nothing else comes up.

+13  A: 

You could do the 2nd option. DateTime.TryParse can help.

shahkalpesh
+3  A: 

I think it depends a bit on how often you expect it to be in the wrong format. Wrapping something in a try-catch doesn't really have any impact at all if the exception is seldom raised. But if you expect it to be raised, a lot, then you should maybe add a check to it.

Svish
+3  A: 

I would go for the second option. I never use exceptions for regular code, because then I can run with the visual studio option "break into debugger when exception is thrown".

This saves me a lot of time when identifying real problems in code, because the debugger will stop at the actual problem instead of somewhere else. If exceptions are used for non-problematic issues I cannot do this reliably.

krosenvold
+2  A: 

Exceptions take a lot of resources to raise and catch. You should avoid letting them be thrown when there are more elegant options available.

Spencer Ruport
+2  A: 

A rule I follow: Always try to catch as many errors manually as you can, and use exceptions as a last resort.

Exceptions have an impact on performance.

Maltrap
A: 

I agree with DateTime.TryParse. I work on a very high volume site and we're not allowed to catch exceptions in the UI, ever!, which helps us to prevent bugs. We try really hard to make sure the code we're calling cannot throw exceptions.

robby valles
If you're ever dealing with user-input, then you are dealing with exceptions. And whether you hide them in "TryParse" or not, it's still necessary to understand where and when exceptions are necessary.
+1  A: 

One thing to note is that "TryParse" will not necessarily be better performance than having a Try Catch around your "Parse".

It depends on your failure rate. Try-Catch's have a performance impact, although most of the impact is when you fail. However, if you have a 95% success rate, or even higher, and performance is a consideration, then you might want to think about wrapping your loop in a try-catch, so that you only hit your "try" statement when there's a failure.

int i = 0;
List<String> prePopulated;
List<DateTime> toPopulate;

while(i < prepopulated.Length)
{
   Try
   {
      while(i < prepopulated.Length)
      {
         List<DateTime>.add(DateTime.Parse(prePopulated[i]));
         i++;
      }
   }
   Catch(Exception ex)
   {
      //log if necessary
      i++;
   }
}

Keep in mind, that solution is only better if your data is primarily clean and performance is key. Otherwise, the simpler one line "TryParse" is better.