Очистка возвращаемых данных базы данных

Лично мне нравится быстро терпеть неудачу - конечно, с должным образом извиняющимся сообщением пользователя. Есть некоторые вещи, от которых стоит избавиться, но что-то вроде столбца, который, как вы ожидаете, будет ненулевым, для меня более важно.

Конечно, я бы также попытался настроить некоторые дымовые тесты, чтобы убедиться, что вы узнали об этом до производства :)

Ограничения базы данных должны позаботиться об этом за вас. В противном случае я бы предложил вернуться к дизайну db и исправить эти ограничения.

В противном случае лучше всего было бы вернуть исключение в этом поле, чтобы данные можно было исправить (или удалить).

Обрабатывайте все, что, по вашему мнению, стоит обрабатывать, и перехватывайте исключения, если произойдет что-то «невозможное».

Как говорит @AviewAnew, вы, возможно, немного параноик, но это не значит, что вы ошибаетесь!

Я бы подумал, что отсутствующий столбец будет намного хуже, чем нулевое значение, так как насчет исключения исключения для отсутствующего столбца?

try // wrap everything in a try/catch to handle things I haven't thought of
{

    if ( !dr.Table.Columns.Contains("column") )
    {
        throw new SomeSortOfException("cloumn: " + column + " is missing" );
    }
    else // strictly don't need the else but it makes the code easier to follow
    {
        if (dr["column"].Equals(DBNull.Value))
        {
            this.value= null;
        }
        else
        {
            this.value = (type) dr["column"];
        }
    }
}
catch( SomeSortOfException ex )
{
    throw;
}
catch( Exception ex )
{
    // handle or throw impossible exceptions here
}

С другой стороны ... если вы собираетесь проводить все эти проверки по всему коду, накладные расходы на обслуживание будут значительными. ... это другое дело.

Ваш звонок!

Я бы приложил ваши усилия, чтобы убедиться, что этого не может произойти, или свести к минимуму шансы, что это может произойти.

Например, из сообщения jonSkeet. Если вы ожидаете ненулевого условия для столбца, есть ли ограничение для этого столбца? Если нет, вы, вероятно, ожидаете этого, потому что разработчик DBA / DB сказал вам, что так и будет. Я бы сказал им, что вы будете полагаться на этот факт и поощрять, подталкивать, уговаривать их добавить ограничение not null. Если вы ожидаете уникальных значений, попросите уникальное ограничение. Только символы верхнего регистра, добавьте ограничение проверки. В вашем коде мало смысла проверять все заглавные буквы, а затем следующее приложение, следующее приложение и следующее приложение, когда это можно сделать один раз. Помните DRY - не повторяйтесь.

В случае ошибки с отсутствующим столбцом мой упреждающий подход заключается в том, чтобы убедиться, что команда разработчиков db понимает, какие таблицы, представления и процедуры используются приложениями. У каждого приложения должно быть собственное имя пользователя, имя пользователя каждого приложения должно иметь право выбора только для тех таблиц, которые ему нужны - нет как функция безопасности, но как документация. Если вы измените ЭТУ таблицу, она будет использоваться этими приложениями. То же самое с procs, предоставьте выполнение приложениям, которые его используют. Если вы будете придерживаться этого принципа и привить отношение "проверять внешние зависимости при внесении изменений", вы избавитесь от многих этих ошибок.