Как убедить других разработчиков не игнорировать исключения?

Question

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

try {
  ...
} catch (XYException e){}

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

Answer 1

Простое правило: ловить исключения, если и только если у вас есть осмысленный способ их обработки . Делайте все, что вам нужно, на рабочем месте, чтобы распространять это простое правило.

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

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

Answer 2

Запустить BadHumour:

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

End BadHumour

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

Answer 3

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

Как сказал Ювал, ловите исключения, только если вы действительно делаете что-то разумное. пусть вещи всплывают, если вы не знаете, что или как с ними справиться. ВОЗМОЖНО обернуть их другими ожидаемыми исключениями (т. Е. DAL может выдать исключение DataLayerException, чтобы более высокие уровни обработки могли обрабатывать все эти вещи в одной попытке / захвате, но не обрабатывать что-то неожиданное).

это нелепый способ ловить исключения и глотать их.

Answer 4

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

В порядке трудностей для начала, вот несколько рекомендаций, которые я видел, эффективно использовались в прошлом:

1. Разговор с разработчиком, указание на проблему и описание того, как это вызвало проблемы для вас. Самое простое решение - не всегда эффективное, и оно будет работать только для этого одного разработчика, но это лучше, чем ничего не делать.
2. Публичный позор. Я работал в местах, где у нас была «Стена позора» с различными ужасами кодирования из нашего проекта, вместе с разработчиком, который их написал. Очень важно, чтобы это было сделано легкомысленно, и я бы не советовал просто начинать с того, чтобы не привлекать всех, но это забавный способ указать на подобные проблемы.
3. Чтение групп. Если у вас есть возможность организовать в вашем офисе группу чтения во время обеденного перерыва, я очень рекомендую это. Подобные проблемы кодирования будут решаться очень хорошо группой чтения, проходящей через "Прагматичный программист".
4. Код отзыва. Опять же, не самая простая вещь для начала, если вы не лидер команды, но это абсолютно стоит предложить вам, если вы не один. Если вы руководитель команды, вам следовало начать проверку кода вчера.

Answer 5

Заголовок не соответствует примеру. В этом примере исключение не игнорируется, а обрабатывается противным образом (иногда это называется проглатыванием исключения) Для этой конкретной болезни я рекомендую статический анализ кода и уменьшение бонуса / зарплаты.

Answer 6

Одна приятная особенность, которая мне нравится в отладчике VS.Net, - это то, что вы можете сказать, что он ломается при возникновении любого исключения. Это не то, что вы включаете все время, но может помочь, когда вы пытаетесь выследить конкретную ошибку. Интересно, существует ли такая же функция для Java, так как это среда, очень похожая на .Net. Я думаю, что эта проблема проявляется больше в Java, чем в .Net, однако, потому что Java требует, чтобы вы обрабатывали исключения или, по крайней мере, помечали свой метод как выдающий то же исключение (AFAIK). Так что, если вам нужно справиться с этим, многие плохие разработчики просто проглотят это, потому что они не имеют ни малейшего представления, как с этим справиться или что с этим делать.

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

Answer 7

Укажите на эту ссылку http://www.ibm.com/developerworks/library/j-jtp05254.html статья, которая объясняет, когда проверять, снимать или бросать или ловить:)

Answer 8

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

Answer 9

Есть несколько тонких путей к этому (каждый из которых является предметом обсуждения)

• Сделайте все подклассы исключений RuntimeException вашего приложения. Таким образом, в вашем приложении нет try / catch, и вы можете легко увидеть (на уровне потока), какая проблема прервала поток. К сожалению, это не влияет на разработчика, который написал этот блок кода именно для того, чтобы избавиться от исключения, которым он не удосужился справиться.
• Используйте Checkstyle или другую статическую проверку кода, чтобы убедиться, что в вашем приложении нет пустого блока catch. К сожалению, это не работает, если в вашей команде не существует непрерывного процесса интеграции (поскольку уведомление об ошибках не отправляется ответственному за них разработчику).
• Предоставьте код шаблона улова по умолчанию с разумным значением (например, logger.log(Level.WARN, "something went wrong here", e)), позволяя пользователю не беспокоиться об управлении исключениями, однако имея достаточно хороший код.