Каков наилучший способ обработки исключений в течение жизненного цикла вашего кода?

Question

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

Какова наилучшая методология обработки таких ситуаций? Какой функционал проще всего использовать для этого в C #?

Десять лет назад в моих классах CS мы просто использовали команду assert (...) в C ++ и позволяли программе запускать бомбу, если что-то использовалось неправильно.

Теперь, когда я использую C #, я использовал два метода, вызывая MessageBox.Show ("..."), чтобы выяснить, почему функция возвращает преждевременно, или Console.WriteLine ("...") чтобы объяснить это только в консоли отладки.

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

Какой метод лучше использовать в таких служебных модулях?

Answer 1

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

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

Answer 2

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

В частности, это означает, что этот путь к коду не будет продолжать, предполагая, что все в порядке. Даже если пользователь (в бета-версии или нет) заметит окно сообщения, он не будет рад узнать, что, как только он нажмет «ОК», приложение запускается и стирает свои данные только потому, что метод использовался неправильно.

Answer 3

Мне нравится ответ pipTheGeek, но я решил добавить плагин для технологии MSR, которая может быть в процессе разработки для C # 4.0: Кодовые контракты

Очевидный ответ - использовать стандартные исключения, входящие в состав библиотек базового класса .Net (ArgumentNullException, InvalidOperationException, NotImplementedException и т. Д.), Или придумать собственное конкретное исключение, если вы чувствуете, что потребителю вашего класса может понадобиться узнать немного больше о том, почему они получают исключение.

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

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

Так как вы спросили о синтаксисе:

    /// <summary>
    /// Summary: 
    ///     Does stuff.
    /// Exceptions:
    ///     ArgumentNullException:
    ///        args must be non-null
    /// </summary>
    /// <param name="args"></param>
    public static void DoStuff(string[] args)
    {
        if(args == null)
        throw new ArgumentNullException("args", "'args' parameter cannot be null.");

        ...
    }

Answer 4

Я согласен с ответом Джона, но у вас также есть Debug.Assert как часть вашего инструментария. Иногда это может помочь вам лучше, если вы хотите что-то предупредить разработчиков, но хотите, чтобы это проскальзывало в рабочем коде.