如果从数据库返回的字符串为null或为空，如何避免异常？

Question

I have a business rules where string needs to be converted to Base64.

The method that execute stored procedure may return a valid string or null string, for example:

public static string GetReturnString()
{
     ...
     try
     {
        con.Open();
        myString = cmd.ExecuteScalar().ToString();
        return myString;
     }
     catch{Exception ex)
     {
        InsertErrorInDB(....);
        return null;
     }
     finally
     {
        con.Close();
        cmd.Close();
     }
}

Then, I have a method that calls above method:

public string GetCode() 
{
   string myString = GetReturnString();
   ConvertToBase64String(myString); // this method will have an exception if myString is null
   .....

}

If I add a check:

if(myString != null || myString.Length !=0)
{
    ConvertToBase64String(myString);   
} 

, I will not have an error, but how to make sure that myString will never be null, so this code will always execute?

What can I write in case if myString does not pass validation condition and is in fact null?

Can I have another attempt to retrieve it from database? Is there any other ways to accomplish that?

Thank you

Answer 1

DBNull.ToString() already returns String.Empty() . You can do the same thing in your exception handler:

public static string GetReturnString()
{
     ...
     try
     {
        con.Open();
        return cmd.ExecuteScalar().ToString();
     }
     catch{Exception ex)
     {
        InsertErrorInDB(....);
        return string.Empty;
     }
     finally
     {
        con.Close();
        cmd.Close();
     }
}

This is least simplifies your test:

if(myString != string.Empty)
{
    myString = ConvertToBase64String(myString);   
}

Also notice that I had to assign back to the original. If you don't do that, you'll throw away the result of the function call.

That's about as close as I can get for you question based on what was provided. For rest of it, we'd need a lot more context, and there are as many ways to handle this as there are programmers in the world.

While I'm here, let me add that re-using the same connection object, as you seem to be doing with the con variable, is poor practice for ADO.Net. You are really better off creating a new connection object for most every call to the database, and instead just re-use the same connection string.