Хорошее соотношение операторов catch к строкам кода

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

Например, в одном фрагменте программного обеспечения, написанного на С#, Visual Studio отображает около 350 строк, содержащих слово "catch", и cloc сообщает, что у нас около 160 тыс. SLOC, 30k прокомментированных строк и 15k пустых строк. 160k/350 - это примерно 467 строк кода для выписки.

Но возьмите это с солью, потому что мы используем стандартное форматирование С# с фигурными скобками на своих собственных линиях, поэтому кто знает, сколько строк - это только отдельные фигурные скобки из 160k, и что 160k подсчитывает некоторые файлы в дереве которые больше не компилируются в приложение и т.д. Я мог бы предположить, что "полезное" отношение будет ближе к 1 catch на 400 LOC.

По крайней мере, к моему удивлению, нам не хватало полукритического исключения, которое попадало в пустой блок catch, поэтому теперь я просматриваю базу кода и, по крайней мере, распечатываю исключение на консоли отладки, временную меру или более конкретную информацию об исключении. Это, конечно же, увеличит количество уловов, которые у нас есть во всем приложении, но приблизит ли мы нас ближе к "приемлемой" зоне? Я понятия не имею, что 1 поймать за 467 LOC - это хорошо, просто хорошо или даже ужасно.

<ч/" > Я хорошо знаю, почему бы не использовать пустые блоки catch. Остальные/предыдущие сопровождающие были ленивы. И так как следующий выпуск этого продукта имеет критический момент, у меня нет времени, чтобы зайти и правильно исправить все 300 (?) Неудовлетворительных заявлений об уловах и проверить правильность работы программного обеспечения (конечно, у нас практически нет автоматизированных тестирование, чтобы сделать это проще:/).

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

Ответ 1

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

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

Ответ 2

Вам не следует ловить исключения, если вы на самом деле не собираетесь их обрабатывать. Если обработчик не может "отменить" исключение или добавить значение каким-либо другим способом, вы должны разрешить исключение для пузырьков до тех, кто может его обработать.

Ответ 3

Я бы полностью проигнорировал любые такие показатели. Подсчет строк кода не обязательно является полезным показателем - особенно при поиске коэффициентов.

Настоящий ответ здесь полностью зависит от контекста. "Правильное" количество операторов catch - это количество блоков try/catch, необходимых для обработки исключений, которые могут произойти, которые вы будете обрабатывать правильно. У вас должен быть блок try/catch вокруг любого исключения, которое может произойти, которое вы можете правильно обработать. Если вы не можете справиться с этим (или не хотите его обрабатывать) правильно, пусть он распространяется вверх - не поймайте его.

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

Ответ 4

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

В отношении других методов я предпочитаю, чтобы они были недоступны; с тем, что, как сказано, есть много раз, что я добавил блоки catch, чтобы добавить состояние в неприятные отчеты об ошибках ( "parameter = value" ), а затем просто "выкидывает" первичный обработчик. Если вы хорошо разбираетесь в своих исправлениях, этот подход приводит к большому количеству мертвого кода.