Question

In this particular application, there is no separate data layer and the data access code is in the Entity itself. For example, consider a Customer entity, then in the Customer.cs file where the members and properties are defined, you have methods to load the Customer object as below

public bool TryLoad(int customerID, out Customer customer)
{
    bool success = false
    try
    {
        //code which calls the db and fills a SqlDataReader
        ReadDataFromSqlDataReader(reader);
        success = true;
    }
    catch(Exception ex)  
    {
      LogError();
      success = false;
    }
    return success;
}

Now, in the ReadDataFromSqlDataReader(reader), tryparse is used to load data from the reader into the object. e.g.

public void ReadDataFromSqlDataReader(reader)
{
   int.TryParse(reader["CustomerID"].ToString(), out this.CustomerID);
   PhoneNumber.TryParse(reader["PhoneNumber"].ToString(), out this.PhoneNumber);
   ... similar TryParse code for all the other fields..
}

Is using TryParse to read all the properties from the reader a good practise? A dev told me that its done this way as TryParse has a better performance than int.Parse. But wouldnt you want an exception to be throw when the value you are reading from the db does not conform to what your code expects? I mean in this case, if there is a wrong phone number in the db then perhaps the object shouldn’t be initialized at all instead of loading an object with an empty phone number?

Answer 1

Yes, following the fail-fast principle, you would want an exception to be thrown the moment a value comes back that cannot be converted into the expected type.

If one of these operations fails and you continue as if nothing happened, you are likely to get weird errors that are hard to catch and hard to pinpoint: objects being added to the database when they should have been updating an existing row, data mysteriously disappearing, dogs and cats living together… you get the idea.

On the other hand, if you throw an exception immediately, you know exactly where your problem is and you can catch it and fix it before it becomes worse.

TryParse will work faster than Parse in case of failure simply because it doesn’t have to throw an exception (which can be expensive), but if you’re assuming that things will succeed (which this code is doing by not using the result of the parse), you should get equivalent performance using Parse.