Ловля конкретного по сравнению с универсальными исключениями в c#
Это варьируется на основе опций, которые Вы передаете install и содержание distutils конфигурационные файлы в системе/в пакет. Я не полагаю, что любые файлы изменяются за пределами каталогов, определенных этими способами.
В частности, distutils не имеет команды удаления в это время.
Это также примечательно, что удаление пакета/яйца может вызвать проблемы зависимости – утилиты как easy_install попытка облегчить такие проблемы.
7 ответов
Вы почти никогда не должны перехватывать исключение верхнего уровня.
В большинстве случаев вам следует перехватить и обработать наиболее конкретное возможное исключение, и только если есть что-то полезное, вы можете с ним сделать.
Исключением (ха-ха) является то, что вы ловите для регистрации и повторно генерируете исключение, тогда иногда нормально перехватить исключение верхнего уровня, зарегистрировать его и повторно выбросить.
Вы почти никогда не должны ловить исключение. Исключение верхнего уровня и проглотите его. Это потому, что, если вы перехватываете исключение верхнего уровня, вы действительно не знаете, что вы обрабатываете; Абсолютно что угодно могло вызвать это, поэтому вы почти наверняка не сможете сделать что-либо, что правильно обработало бы каждый случай сбоя. Вероятно, есть какие-то сбои, которые вы можете просто молча обработать и проглотить, но, просто проглатывая исключения верхнего уровня, вы также проглотите целую кучу, которая действительно должна была быть выброшена вверх, чтобы ваш код обрабатывал выше. В вашем примере кода вы, вероятно, захотите обработать SQLException и записать + проглотить это; а затем для исключения зарегистрируйте и повторно выбросьте его. Это прикрывает себя. Вы по-прежнему регистрируете все типы исключений, но проглатываете только довольно предсказуемое SQLException, которое указывает на проблемы с вашим SQL / базой данных.
Обычной практикой является обработка только всех исключений, которые вы действительно можете разрешить в этот момент, если можете не разрешите это в этой точке кода, тогда вы позволите ему всплыть вверх. Если вы не можете решить его на следующем уровне, позвольте ему продолжить. Если он достигнет вершины без обработки, покажите пользователю вежливое извинение (возможно, попытайтесь выполнить быстрое автосохранение) и закройте приложение. Обычно считается худшим разрешить приложению продолжать работу после необработанного исключения, потому что вы не можете предсказать состояние приложения, поскольку произошло что-то исключительное. Лучше просто выключить и перезапустить приложение, чтобы вернуться в ожидаемое состояние.
Вам следует прочитать общий документ или Google «Обработка структурированных исключений» и получить более полное представление о том, о чем идет речь в этой теме, но в целом перехват каждого исключения считается плохой практикой, потому что вы понятия не имею, что это было за исключение (ошибка памяти, ошибка нехватки памяти, сбой диска и т. д.).
И для многих неизвестных / неожиданных исключений вы не должны позволять приложению продолжать работу. В общем, вы «ловите» и обрабатываете только те исключения, которые игрушка определила в результате анализа метода, для которого вы кодируете предложение catch, которые этот метод фактически может создать и с которыми вы можете что-то сделать. Единственный раз, когда вы должны поймать все expcetoins (catch Exception x), - это сделать что-то вроде регистрации,
Взгляните на эту статью Кшиштофа Квалины, которая, как я считаю, очень полезна для понимания того, когда перехватывать или игнорировать исключения:
Как создать исключение Иерархии
Все описанные в нем принципы построения иерархий исключений также применимы при принятии решения о том, когда перехватывать, генерировать или игнорировать исключения. Он делит исключения на три группы:
- Ошибки использования , такие как
DivideByZeroException, которые указывают на ошибки в коде; вы не должны обрабатывать их, потому что их можно избежать, изменив код. - Логические ошибки , например,
FileNotFoundException, с которым вам нужно справиться, потому что вы не можете гарантировать, что этого не произойдет. (Даже если вы проверите наличие файла, он все равно может быть удален за долю секунды до того, как вы прочитаете из него.) - Системные сбои , такие как
OutOfMemoryException, которые вы можете ' Не избегайте и не обращайтесь.
Да,
Вы должны перехватывать от наиболее конкретного исключения до наименьшего, чтобы вы могли справиться с вещами соответствующим образом.
Например, если вы создавали веб-запрос, вы должны сначала поймать такие вещи, как TimeOuts и 404, затем вы можете сообщить конечному пользователю, что они должны повторить попытку (тайм-аут) и / или проверить введенный URL.
Затем вы можете поймать что-то менее общее, в случае чего немного более дурацкий идет не так, а затем сразу же возвращайтесь к простому перехвату исключения в случае, если произойдет что-то нелепое.
Рекомендуется избегать перехвата Exception и использование флагов в качестве возвращаемых значений.
Вместо этого вам следует разработать собственные исключения для ожидаемых исключений и перехватывать их напрямую. Все остальное должно появиться как неожиданное исключение.
В приведенном выше примере вы можете повторно создать исключение, более специфичное для бизнеса.
Я согласен с инструментом анализа кода. Мое исключение из этого правила состоит в том, что я перехватываю общее исключение в своих обработчиках событий, и пользователю предоставляется возможность сообщить об ошибке или проигнорировать ее.
В приведенном вами примере, я думаю, анализ кода сделал все правильно. Если вы не можете обработать конкретное исключение прямо здесь, вы не должны вообще ничего ловить и позволять ему подниматься до самого высокого уровня. Таким образом, вам будет намного проще воссоздать проблему, когда вы попытаетесь ее исправить.
Вы можете улучшить свой пример, добавив строку подключения и значение идентификатора в исключение ' s Свойство данных и убедитесь, что оно также зарегистрировано. Так вы дадите себе шанс воспроизвести ошибку.
Я согласен с тем, что, как правило, вы должны перехватывать только ожидаемые исключения и понимать, как их обрабатывать. Несколько случаев, когда я часто этого не делаю:
Как упоминалось выше, если я собираю какую-то полезную информацию для регистрации, а затем повторно загружаю.
Если я выполняю асинхронную операцию, такую как обработка сообщений в очереди или заданий в рабочем потоке, и я хочу перехватить исключение для повторной генерации в другом контексте. Я также часто использую здесь уродливый прием, который обманом заставляет CLR добавлять информацию трассировки стека, чтобы она не терялась при повторном вызове в новом контексте.
Если я работаю с изолированной задачей или операцией, и я могу обработать исключение, завершив задачу, без завершения всего приложения. Мне часто хочется, чтобы здесь было исключение верхнего уровня для действительно фатальных исключений (например, OutOfMemoryException), поскольку я их игнорировал. Правильный способ справиться с этим - запустить изолированную задачу в ее собственном домене приложений, но у меня еще не было доступного времени для реализации этого в проекте.