Как сделать обработку и отслеживание исключений в C #

Question

Я читаю некоторые книги по C # и получил некоторое упражнение, не знаю, как это сделать, или не уверен, что означает вопрос.

Проблема:

После того, как вы проработали какое-то время в компании, ваши навыки знающего разработчика признаются, и перед вами стоит задача «контроля» за реализацией обработки и отслеживания исключений в исходном коде (C #) для корпоративного приложения, которое постоянно развивается. Две цели, поставленные архитектором продукта:

1. 100% методов во всем приложении должны иметь хотя бы стандартный обработчик исключений, использующий блоки try / catch / finally; более сложные методы также должны иметь дополнительную обработку исключений для конкретных исключений

2. Весь код потока управления может дополнительно записывать информацию «трассировки», чтобы помочь в отладке и инструментарии приложения во время выполнения в ситуациях, когда традиционные отладчики недоступны (например, на промежуточных и производственных серверах).

(Я не совсем понимаю эти критерии, я пришел из мира java, у java есть два вида исключений: проверенное и непроверенное исключение. Разработчик должен обработать проверенное исключение и вести регистрацию. Применительно к непроверенному исключению, возможно, ведение журнала возможно, но большую часть времени мы просто бросаем его. Однако здесь речь идет о C #, что мне делать?)

Вопрос к задаче:

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

2. Как бы вы обеспечили соответствие всего существующего кода правилам, указанным архитектором продукта; в частности, какие соображения повлияют на ваше планирование работы для обеспечения соответствия всего существующего кода?

Answer 1

Как вы упомянули, Java проверяла и не проверяла исключения. Для проверенных исключений вы должны либо объявить, что ваш метод выдает его, либо обработать исключение в методе. C # не имеет такого ограничения, ваш метод не должен объявлять, какое исключение он может вызвать.

100% методов во всем приложении должны иметь хотя бы стандартный обработчик исключений, использующий блоки try / catch / finally; более сложные методы также должны иметь дополнительную обработку исключений для конкретных исключений

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

---

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

И для хорошей меры Vexing исключения .

Answer 2

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

• Не перехватывать исключения, если не может быть добавлено какое-либо значение. Другими словами, если знание об исключении бесполезно для пользователя, для вас или для приложения, не отлавливайте его.
• Делайте исключения, если вы хотите повторить операцию, добавить соответствующую информацию в исключение, скрыть конфиденциальную информацию, содержащуюся в исключении, или отобразить отформатированную информацию.
• Обычно обрабатывают исключения только на границе приложения (например, на вершине логического уровня, на уровне, на границе службы или на вершине уровня пользовательского интерфейса). Кроме того, замените исключения, содержащие конфиденциальную информацию, новыми исключениями, которые содержат информацию, которая может безопасно передаваться за пределы текущей границы.
• Не распространять конфиденциальную информацию через границы доверия. Это стандартное соображение безопасности, но оно часто упускается из виду при работе с информацией об исключениях. Вместо этого замените исключения, которые содержат конфиденциальную информацию, новыми исключениями, которые содержат информацию, которая может безопасно передаваться за пределы текущей границы.
• Сделайте исключения как можно более точными и разрешите выполнение конкретных действий при возникновении исключения. Иногда это может потребовать написания пользовательских исключений с необходимыми атрибутами.
• Сообщения об ошибках, отображаемые для пользователей, должны быть релевантными и предлагать корректирующие действия. В большинстве случаев отображаемые пользователем сообщения об ошибках никогда не должны содержать конфиденциальную информацию, такую ​​как следы стека или имена серверов.