Правильное время для обработки всех исключений

Question

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

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

А ты? когда вы, ребята, позаботитесь об исключениях?

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

Я бы сказал, что это задом наперед (но часто).

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

Иногда это зависит от технологии или целевой платформы. Я обычно предпочитаю слой обработки исключений, который заботится обо всех исключениях. Каждый блок кода находится внутри блока try catch.

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

Answer 8

Правило для того, чтобы ловить исключения, обычно таково: где бы вы ни находились, где вы можете их осмысленно обработать.

Answer 9

Ответ на этот вопрос очень четкий, «это зависит».

Вам нужно посмотреть на конкретную ситуацию; генерируется ли исключение в определенном фрагменте кода, где можно восстановить или обработать «исключительную» ситуацию, приводящую к возникновению исключения? В таком случае, да, поймайте исключение и разберитесь с ним на этом уровне.

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