Можно ли написать код, который наносит ущерб, который не может быть исправлен путем прекращения процесса? - PullRequest
Новая
       23

Можно ли написать код, который наносит ущерб, который не может быть исправлен путем прекращения процесса?

2 голосов
/ 28 апреля 2011

Этот вопрос был в моей памяти в течение многих лет.Я добавляю немного истории / контекста.

Когда я программировал C ++ в тот день, у меня было твердое понимание «утечки памяти»: вы вызываете новый X, а затем вызываете delete X. Если вы неЕсли вы не выполняете вторую часть слишком много раз, вы можете увидеть эффект неограниченного увеличения объема оперативной памяти, потребляемой вашей программой.

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

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

С объектами .NET автоматически подсчитывается ссылка, и фоновый поток занимает память, потребляемую выделениями дляосиротевшие объекты.Но есть и такие вещи, которые намекают на возможность провала, как термин «неуправляемый ресурс».

До сих пор я чувствовал себя «в безопасности», всегда следуя шаблону, который я вижу, например,если я захочу запросить SQL, я сначала поищу его в Google и найду что-то вроде: 

public DataTable GetData(SqlCommand cmd)
{
    DataTable dt = new DataTable();
   String strConnString  
   =System.Configuration.ConfigurationManager.ConnectionStrings["conString"].ConnectionString;
    SqlConnection con = new SqlConnection(strConnString);
    cmd.Connection = con;
    SqlDataAdapter sda = new SqlDataAdapter();
    cmd.CommandType = CommandType.Text;
    try
    {
        con.Open();
        sda.SelectCommand = cmd;
        sda.Fill(dt);
    }
    catch
    {
        return dt;
    }
    finally
    {
        con.Close();
        cmd.Dispose();
        sda.Dispose();
    }
    return dt;
}

Моя проблема в том, что я никогда не удосужился спросить: «Что если я не закрыл соединение?»- Я просто использую технику копирования / вставки и продолжаю.

Появление инструментов фрагментов кода, таких как LinqPad, заставило меня снова задуматься об этом, потому что я часто испытывал искушение поиграться с API, как, например, я.просто запустил фрагмент: 

string qbConStr = @"DSN=QuickBooks Data;SERVER=QODBC;OptimizerDBFolder=%UserProfile%\QODBC Driver for QuickBooks\Optimizer;OptimizerAllowDirtyReads=N;SyncFromOtherTables=Y;IAppReadOnly=Y";
OdbcConnection connection = new OdbcConnection(qbConStr);
connection.Open();
connection.GetSchema();

Мне не хотелось использовать «хорошую форму», потому что, в конце концов, это фрагмент, верно?

Вопрос: Верно?

1 Ответ

2 голосов
/ 28 апреля 2011

Я не знаю, как вы можете вызвать утечку рукоятки / неисправимый ущерб, который не может быть исправлен путем завершения процесса - я уверен, что это возможно, но вам нужно делать это изо всех сил (неудачазакрытие соединений с базой данных файловых дескрипторов не приведет к этому - они будут выпущены ОС, как при завершении процесса).

FYI, вместо использования try-catch, таким образом, вы должны просто использовать dispose вместо этого - под одеялом он делает то же самое, но результат получается чище и легче читается: 

public DataTable GetData(SqlCommand cmd)
{
    DataTable dt = new DataTable();
    string strConnString  = ConfigurationManager.ConnectionStrings["conString"].ConnectionString;
    using (SqlConnection con = new SqlConnection(strConnString))
    {
        cmd.Connection = con;
        using (SqlDataAdapter sda = new SqlDataAdapter())
        {
            cmd.CommandType = CommandType.Text;
            con.Open();
            sda.SelectCommand = cmd;
            sda.Fill(dt);
        }
    }
    return dt;
}

Вам также следует избегать перехвата исключений - если вышеизложенное создает исключение, лучше, еслизвонящий обрабатывает это.Также вы должны оставить распоряжение SqlCommand до вызывающей стороны, поскольку они передали команду и, возможно, захотят использовать ее повторно.

Последнее замечание о dispose и одноразовых объектах - дескрипторах и другой операционной системе.ресурсы будут очищены после завершения процесса, но это не то же самое, что вызов метода dispose, который не выполняется автоматически при завершении процесса.Это важно в определенных ситуациях, например, при использовании StreamWriter для записи в файл.Этот поток буферизован, и поэтому, если вы не вызовете Flush (или Dispose, который, в свою очередь, вызывает Flush), вы можете обнаружить, что полученный текстовый файл обрезан.

...