Как сделать обработку и отслеживание исключений в 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

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

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