Предупредить, если исключение не обработано - PullRequest
2 голосов
/ 06 декабря 2011

Существуют ли методы или сторонние инструменты, которые будут генерировать предупреждения, если код может вызвать исключение, которое не заключено в блок try/catch?

Ответы [ 3 ]

3 голосов
/ 06 декабря 2011

Я бы предположил, что вам лучше подумать о , почему код генерирует исключения, в отличие от простого и без дальнейшего рассмотрения требования, чтобы весь код был заключен в какой-нибудь try / catch / finally или другой.(Между прочим, если бы это было возможно, было бы тривиально убрать его из строя - разработчики могли бы просто обернуть главную точку входа в попытку / улов, и больше никаких предупреждений).

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

Я бы сохранил обработку исключений для местгде вы имеете дело с внешними факторами, которые находятся вне вашего контроля (например, пользователь отключает сетевой кабель, когда ваше приложение загружает файл).Мне кажется, что вы ищете проверенные исключения в стиле Java, которых нет в C #.Но если вы посмотрите на метод XML-комментариев для внешних библиотек, вы сможете увидеть, какие исключения они могут генерировать, и обработать эти конкретные случаи.Если вы действительно делаете это только для внешних целей (и используете кодовые контракты для управления внутренними предположениями), то потраченное дополнительное время будет невелико.

0 голосов
/ 06 декабря 2011

Наряду с ответом Эрика (с голосом выше):

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

Если у ваших методов есть ситуации «пройти / не пройти», то они должны возвращать логический флаг.Если они немного сложнее, например, требуется возвращать коды состояния, то вам следует использовать структуру или класс в качестве результата.

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

0 голосов
/ 06 декабря 2011

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

Тем не менее, ответ на принятый вопрос там:

Следуя моему предыдущему ответу, мне удалось создать базовый Искатель исключений. Он использует класс ILReader, основанный на отражении, доступный здесь на блоге MSDN Хайбо Ло. (Просто добавьте ссылку на проект.)

[...]

Подводя итог, этот алгоритм рекурсивно перечисляет (сначала в глубину) любой методы, вызываемые в пределах указанного, читая CIL инструкции (а также отслеживание уже посещенных методов). Это поддерживает единый список коллекций, которые могут быть выброшены с помощью Объект HashSet, который возвращается в конце. Это дополнительно поддерживает массив локальных переменных и стек, чтобы сохранить отслеживание исключений, которые не генерируются сразу после создано.

Если вы не возражаете против пост-компиляции анализа кода на основе IL-кода, вы можете попробовать использовать фрагмент Noldorin, размещенный в этом вопросе.

...