Профилактический по сравнению с Реактивным программированием C#

Существуют некоторые случаи, где Вы вынуждены быть реактивными: Проверьте и действуйте, не всегда работает.

Доступ к файлу на диске: диск работает? файл существует? я могу получить доступ для чтения к файлу?

Доступ к базе данных: сервер принимает соединения? Действительно ли мои учетные данные хороши? Объекты базы данных существуют? Действительно ли столбцы named/typed соответственно?

Все эти вещи могут измениться между проверкой и операцией.

В мои дни COM C++ я учился не наклоняться назад для обработки "возможных" ошибок - то есть, я обычно не проверяю возвращаемое значение каждого вызова функции. Поэтому я знаю, что не могу успешно выполниться при обработке неизвестных условий:

• Я не знаю, когда это перестанет работать, или что это означает.

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

• Я не знаю то, что пользователь хотел бы, чтобы я сделал.

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

• Сбой быстро и существенно (вместо медленно и тонко) не убаюкивает пользователя в к ложному чувству защищенности и дает программисту лучший шанс при диагностировании проблемы.

Очевидно, я не говорю, "никогда не обрабатывают ошибки", говорю я, "только обрабатывают ошибки, когда можно увеличить стоимость".

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

Как обычно, ответ, "он зависит", но я подписываю на "сбой быстро" философию в целом.

Я предпочитаю использовать попытку/наконец (без выгоды), если я не могу на самом деле сделать что-то полезное для восстановления с исключения в конкретном блоке кода. Ловля каждого возможного исключения не стоит того. В целом сбой быстро предпочтителен для сбоя тихо.

Если с другой стороны, Вы знаете, как восстановиться с конкретного исключения, то да, пойдите, делают это.

Скажите, что у Вас есть библиотека передачи файлов. Это, вероятно, выдаст исключение, если передача будет прервана из-за тайм-аута или отказа сети. Это разумно. Вы будете раздражаться, если библиотека просто перестанет работать тихо; проверка код возврата намного более подвержена ошибкам, и не обязательно более читаема. Но возможно у Вас есть бизнес-правило для отправки набора файлов к серверу, что необходимо предпринять по крайней мере 3 попытки передать файл перед отказом и просьбой о вмешательстве пользователя. В этом случае бизнес-логика должна обработать исключение, попытаться восстановить, затем сделать то, что это, как предполагается, делает, когда автоматическое решение перестало работать (предупредите пользователя, запланируйте более позднюю попытку, или безотносительно).

Если Вы находите код, который делает это:

try
{
    // do something that could throw
    // ...
}
catch {} //swallow the exception

или:

catch { return null; }

Это, вероятно, повреждается. Несомненно, иногда кодируйте это, Вы звоните, может выдать исключение, о котором Вы действительно не заботитесь. Но я часто вижу, что люди делают это именно так, они не должны "обрабатывать" исключение в восходящем направлении; практика делает вещи тяжелее для отладки.

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

Иногда, я буду пробовать/ловить и выдавать другое, более соответствующее исключение. Однако, если это возможно, защитный пункт лучше. e, g. if (argument==null) throw new ArgumentNullException(); лучше, чем разрешение NullReferenceException распространить стек вызовов, потому что более ясно, что пошло не так, как надо.

Некоторых условий "никогда не должно происходить" или "Я не знал, что это могло произойти", должен, вероятно, быть зарегистрирован (см., например, jboss регистрирующийся), но может глотаться, прежде чем они снизят Ваше приложение по крайней мере в некоторых случаях.

ETA: Это, вероятно, повреждается, чтобы взять определенное исключение и затем отобразить общее, неоднозначное сообщение об ошибке. Для Вашего второго примера выше, который звучит плохим мне. Для Вашего первого, "Файл, не найденный", который может быть более разумным (если Вы на самом деле ловите то определенное исключение и не только "все"), если у Вас нет лучшего способа иметь дело с тем условием где-то в другом месте. Модальные Messageboxes обычно являются плохим "запахом дизайна взаимодействия" мне, но это главным образом не относится к делу.

Я полагаю, что Вы корректны, что использование исключений, как проверяют утверждения, является плохой практикой. Исключения в .NET являются медленными. Всегда намного лучше сделать Ваши собственные проверки вместо того, чтобы использовать исключения для ловли "плохих" значений, тех, которые Аннулируют как Jon B упомянутый.

Я узнал на собственном опыте в приложении.Net 1.1, которое создало файлы разделенного текста данных лаборатории. Я использовал исключения для ловли полей, которые имели недопустимые данные, но после того как я заменил исключения соответствующим кодом проверки, приложением, ускоренным экспоненциально.

Ввод блока попытки в C++ является дорогой операцией (с точки зрения циклов ЦП), таким образом, необходимо минимизировать использование их по этой причине. Для C#, вводя блок попытки является дешевым, таким образом, мы можем использовать его по-другому.

Теперь; ловля исключений в C# является дорогой, и все еще должна все еще использоваться для исключительных случаев а не для общей логики программы, как другие уже заявили здесь...

Подсказка находится в термине "Исключение".

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

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

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

Я когда-то должен был отладить приложение, где каждое мыслимое проклятое исключение было обработано, и было буквально невозможно отладить. Это должно было быть вытащено производства, в dev envt, наряду с его базой данных и всеми сорванными обработчиками. После этого это было тривиально.

C/C++ может быть столь же реактивным. Сколько раз Вы видели, что что-то попыталось, такие как fopen, который будет сопровождаться ПУСТОЙ проверкой? Преимущество для исключений состоит в том, что они позволяют большей информации быть данной, чем ПУСТОЙ или Ложный возврат.

Большинство операций, которые выдают исключения на любом языке, который поддерживает их, нет никакого способа "Протестировать" перед рукой, чтобы удостовериться, что операция успешно выполнится.

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

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

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

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

Для хорошей начальной точки на обработке исключений и стратегии, посмотрите Исключения сообщения в блоге Ned Batchelder в Дождевом лесу.