Правильное время для обрабатывания всех исключений
/* Находят фиксированный диск с самым большим свободным пространством, можно также скопировать файлы для оценки, какой диск самым быстрым * /
EXEC master..xp_fixeddrives
предположения Проверки/* о файле перед использованием или ссылкой * /
EXEC master..xp_fileexist 'C:\file_you_want_to_check'
9 ответов
Лично я всегда определяю глобальный диспетчер необработанных исключений, соответствующий типу приложения, и отправляю этот журнал и электронную почту моей команде разработчиков. Затем во время контроля качества мы начнем добавлять управление исключениями к процедурам, имеющим предсказуемые (и исправимые) проблемы. Во всех возможных случаях мы добавляем защитный программный код, чтобы исключения вообще не происходили. (Нет необходимости перехватывать исключение, если вы можете протестировать, прежде чем пробовать код, который может дать сбой.)
Мои приложения, как правило, заканчиваются большим количеством защитного кода (который должен быть встроен с самого начала) и только некоторыми конкретными исключениями. обработка.
Я бы сказал, что это наоборот (но обычное дело).
Возможно, вы захотите изучить разработку, основанную на тестировании, и протестировать первый дизайн
Подсказка: подумайте о поведении, напишите код для проверки, добавьте его в свое приложение.
Я бы определенно рассмотрел исключения, возникающие при разработке каждого интерфейса и модуля.
Таким образом вы можете проверить, что они надежно брошены (когда вы ожидаете, а не когда нет). Компоненты, использующие эти компоненты, затем могут быть написаны так, чтобы они знали об этих исключениях и обрабатывали их (или не так, как они того требуют).
Мне кажется, что вы игнорируете некоторые функции разрабатываемых вами компонентов. Я практически всегда проверяю правильность работы и исключительные обстоятельства, чтобы охватить как можно больше сценариев как можно раньше.
Ответ на этот вопрос - очень четкий: «это зависит от обстоятельств».
Вам нужно взглянуть на конкретную ситуацию; генерируется ли исключение в конкретном фрагменте кода, в котором можно восстановить или обработать «исключительную» ситуацию, в результате которой возникло исключение? В таком случае, да, перехватите исключение и обработайте его на этом уровне.
С другой стороны, вы говорите о неисправимых ошибках? Тогда, конечно, поймайте их на более глобальном уровне или, возможно, не поймите вообще (например, если вы ничего не можете поделать с исключением, почему вы его поймаете?)
Обычно правило, где перехватывать исключения: где бы вы ни находились, вы можете осмысленно обработать их.
Я предпочитаю разработку через тестирование. Если есть ожидаемая ошибка, проверьте ее. Если возникает непредвиденная ошибка, проверьте ее, а затем исправьте.
Иногда это зависит от технологии или целевой платформы. Обычно я предпочитаю уровень обработки исключений, который заботится обо всех исключениях. Каждый блок кода находится внутри блока try catch.
Суть в том, что никакое исключение не должно перехватывать ОС или любой другой объект вне программы или кода.
Прелесть исключений по сравнению с возвратом кодов ошибок из API в том, что вам не нужно проверять исключения на всех уровнях вашего кода. Вы можете перехватить определенные исключения, чтобы определить конкретные условия ошибки и, возможно, обработать ошибку или повторно создать более подходящее исключение. Вы также должны перехватывать исключения на высоком уровне в вашем приложении, чтобы избежать необработанных исключений.
Следует отметить, что обычно пользователь исключения является разработчиком, а не конечным пользователем. Последний обычно не понимает технических деталей исключений.
Чаще всего я видел, что разработчики сознательно выбирают, на каком уровне обрабатывать исключения и разрешать их выброс. Обычно это будет на уровне рабочего потока или на высоком уровне бизнес-логики. Разрешить возникновение исключений и иметь общий метод их обработки / регистрации и защиты пользователя от них.
Время - единственная разница между тем, что обычно происходит, и тем, что вы делаете. Планируйте это в своих приложениях с самого начала и выполняйте обработку исключений на высоких уровнях.
Исправление определенных исключений выполняется с помощью вашего метода исправления, когда это проблема. Иногда библиотека, которую я использую, будет без нужды использовать исключения для передачи информации, и я добавлю специализированную обработку исключений для всех вызовов этой библиотеки. Часто я делаю это в классе-оболочке, который скрывает реализацию и обработку исключений от остальной части моего приложения.