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

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

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

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

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

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

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

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

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

// 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).

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

Ваш исходный код:
public Point CalculatePoint (... out Boolean boSuccess);
общедоступный список CalculateListOfPoints (... out Boolean boSuccess);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

public static readonly Point Empty

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

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

Класс 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; 
            }
    }
}

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