Как указать, что метод был неудачен

Для подведения итогов существует несколько подходов, которые можно проявить:

1. , Когда тип возврата является типом значения, как Точка, используют функцию Nullable C# и возвращают Точку? (иначе Nullable), тот способ, которым можно все еще возвратить пустой указатель при отказе
2. , Выдают исключение, когда существует отказ. Целым аргументом/обсуждением относительно того, что и не является "исключительным", является спорный вопрос, это - Ваш API, Вы решаете то, что является исключительным поведением.
3. Принимают модель, подобную реализованному Microsoft в базовых типах как Int32, обеспечивают CalculatePoint и TryCalculatePoint (int32. Синтаксический анализ и int32. TryParse), и имеют один бросок и один возврат bool.
4. Возврат универсальная структура из Ваших методов, которая имеет два свойства, bool Значение GenericType и Успех.

Зависящий от сценария я склонен использовать комбинацию возврата пустого указателя или выдачи исключения, поскольку они кажутся "самыми чистыми" мне и подходят лучше всего с существующей кодовой базой в компании, на которую я работаю. Таким образом, моя персональная лучшая практика была бы подходами 1 и 2.

Модель, которую я использовал, является тем же использование MS с методами TryParse различных классов.

Ваш исходный код:
общедоступная Точка CalculatePoint (... булевская переменная boSuccess);
общедоступный Список CalculateListOfPoints (... булевская переменная boSuccess);

превратился бы в общедоступный bool CalculatePoint (... (или касательно) Точка CalculatedValue);
общедоступный bool CalculateListOfPoints (... (или касательно) Список CalculatedValues);

В основном Вы делаете успех/отказ возвращаемым значением.

Если отказ по определенной причине тогда, я думаю, что хорошо возвращает пустой указатель или bool и имеет параметр. Если однако Вы возвращаете пустой указатель независимо от отказа тогда, я не рекомендую это. Исключения обеспечивают богатый набор информации включая причину, ПОЧЕМУ что-то отказавшее, если все Вы возвращаетесь, является пустым указателем тогда, как Вы знаете, имеете ли, потому что данные являются неправильными, Вы, исчерпал память или некоторое другое странное поведение.

Даже в .NET TryParse имеет брата Синтаксического анализа так, чтобы можно было получить исключение, если Вы хотите.

, Если бы я предоставил метод TrySomething, я также предоставил бы Чему-то метод, который выдал исключение в случае отказа. Тогда это до вызывающей стороны.

Другая альтернатива должна выдать исключение. Однако Вы обычно только хотите выдать исключения в "исключительных случаях".

, Если случаи возникновения отказов являются распространенными (и не исключительными), то Вы уже перечислили свои две опции. РЕДАКТИРОВАНИЕ : может быть конвенция в Вашем проекте как, как обработать такие неисключительные случаи (нужно ли возвратить успех или объект). Если нет никакой существующей конвенции, то я соглашаюсь с lucasbfr и предлагаю, чтобы Вы возвратили успех (который соглашается с тем, как TryParse (...) разработан).

Почему они перестали бы работать? Если это из-за чего-то, что вызывающая сторона сделала (т.е. обеспеченные аргументы), тогда бросок ArgumentException является совершенно соответствующим. Попытка [...] метод, который избегает исключения, прекрасна.

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

Возвратитесь Точка. Пустой . Это - скороговорка дизайна.NET для возврата специального поля, когда Вы хотите проверить, было ли создание структуры успешно. Избегайте параметры, когда Вы будете мочь.

public static readonly Point Empty

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

Мы однажды записали всю Платформу, где все открытые методы любой возвращенный true (выполняемый успешно) или ложь (ошибка произошла). Если мы должны были возвратить значение, мы использовали выходные параметры. Вопреки широко распространенному мнению этот способ запрограммировать на самом деле упростил много нашего кода.

Вы не хотите выдавать исключения, когда существует что-то, ожидал происходить, как @Kevin указанные исключения для исключительных случаев.

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

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

Хорошо с Точкой, можно передать Точку обратно. Пустой как возвращаемое значение в случае отказа. Теперь все это действительно делает возвратить точку с 0 для значения X и Y, поэтому если бы это может быть допустимым возвращаемым значением, я избегал бы этого, но если Ваш метод никогда не будет возвращаться (0,0) точка, то можно использовать это.

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

// NB:  A bool is the return value. 
//      This makes it possible to put this beast in if statements.
public bool TryCalculatePoint(... out Point result) { }

public Point CalculatePoint(...)
{
   Point result;
   if(!TryCalculatePoint(... out result))
       throw new BogusPointException();
   return result;
}

Лучше всего обоих миров!

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

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

Шаблон, с которым я экспериментирую, возвращается , Возможно . Это имеет семантику шаблон TryParse , но подобная подпись к null-return-on-error шаблону.

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

, Возможно, класс выглядит примерно так:

/// <summary>
/// Represents the return value from an operation that might fail
/// </summary>
/// <typeparam name="T"></typeparam>
public struct Maybe<T>
{
    T _value;
    bool _hasValue;


    public Maybe(T value)
    {
        _value = value;
        _hasValue = true;
    }

    public Maybe()
    {
        _hasValue = false;
        _value = default(T);
    }


    public bool Success
    {
        get { return _hasValue; }
    }


    public T Value
    {
        get 
            { // could throw an exception if _hasValue is false
              return _value; 
            }
    }
}

bool TrySomething () является, по крайней мере, практикой, которая работает хорошо на методы синтаксического анализа .NET, но я не думаю, что мне нравится он в целом.

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

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

Однако - Ваш подход является немного процедурным - что относительно того, чтобы создать что-то как класс PointCalculator - взятие необходимых данных как параметры в конструкторе? Тогда Вы называете CalculatePoint на нем и получаете доступ к результату через свойства (раздельное имущество для Точки и для Успеха).

Это главным образом зависит от поведения Ваших методов и их использования.

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

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

И иногда оба пути имеют смысл...