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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запустите BadHumour:

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

End BadHumour

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