Как указать, что метод не удался

Лично я бы использовал ту же идею, что и TryParse (): используя параметр out для вывода реального значения и возвращая логическое значение, указывающее, был ли вызов успешным или нет.

public bool CalculatePoint(... out Point result);

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

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

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

Другой альтернативой является создание исключения. Однако обычно вы хотите создавать исключения только в «исключительных случаях».

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

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

Даже в .net у TryParse есть брат Parse, так что вы можете получить исключение, если хотите.

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

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

Ваш исходный код:
public Point CalculatePoint (... out Boolean boSuccess);
public List CalculateListOfPoints (... out Boolean boSuccess);

Превратится в public bool CalculatePoint (... out (или ref) Point CalculatedValue);
public bool CalculateListOfPoints (... out (или ref) List CalculatedValues);

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

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

1. Если возвращаемый тип является типом значения, например Point, использовать функцию C #, допускающую значение NULL, и вернуть Point? (также известный как Nullable), таким образом вы все равно можете вернуть null при сбое
2. Выбрасывать исключение при сбое. Вся аргументация / обсуждение того, что является «исключительным», а что нет, - это спорный вопрос, это ваш API, вы решаете, что является исключительным поведением.
3. Примите модель, аналогичную той, которая реализована Microsoft в базовых типах, таких как Int32, предоставьте CalculatePoint и TryCalculatePoint (int32.Parse и int32.TryParse) и сделайте один бросок и один возврат логического значения.
4. Верните универсальную структуру из ваших методов, которая имеет два свойства: bool Success и GenericType Value.

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

В основном это зависит от поведения ваших методов и их использования.

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

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

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

Верните Point.Empty. Это шаблон дизайна .NET, чтобы возвращать специальное поле, когда вы хотите проверить, было ли создание структуры успешным. По возможности избегайте out параметров.

public static readonly Point Empty

Шаблон, с которым я экспериментирую, возвращает Может быть. Он имеет семантику шаблона TryParse, но схожую сигнатуру с шаблоном возврата с нулевым значением при ошибке.

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

Класс Maybe выглядит примерно так:

/// <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; 
            }
    }
}

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

В приведенных вами примерах я не вижу причин, по которым вам не следует использовать " rel="nofollow noreferrer" исключения в случае сбоя.

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

// 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;
}

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

Bool TrySomething () - это, по крайней мере, практика, которая работает нормально для методов синтаксического анализа .net, но я не думаю, что мне это нравится в целом.

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

Возвращать null, когда это возможно, в большинстве случаев нормально, когда вам не нужно исключение.

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

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

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

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

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

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

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