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

Question

У меня есть несколько похожих методов, скажем, например. CalculatePoint (...) и CalculateListOfPoints (...). Иногда они не могут быть успешными, и должны указать это вызывающей стороне. Для CalculateListOfPoints, которая возвращает общий список, я мог бы вернуть пустой список и потребовать, чтобы вызывающий проверил это; однако Point является типом значения, поэтому я не могу вернуть значение null.

В идеале я бы хотел, чтобы методы выглядели одинаково; Одним из решений может быть определение их как

public Point CalculatePoint(... out Boolean boSuccess);
public List<Point> CalculateListOfPoints(... out Boolean boSuccess);

или в качестве альтернативы вернуть балл? для CalculatePoint и возвращаемое значение NULL для обозначения ошибки. Это означало бы необходимость возврата к ненулевому типу, что кажется чрезмерным.

Другим способом было бы вернуть логическое значение boSuccess, иметь результат (Point или List) в качестве параметра 'out' и вызывать их TryToCalculatePoint или что-то ...

Что такое лучшая практика?

Редактировать: я не хочу использовать исключения для управления потоком! Иногда ожидается сбой.

Answer 1

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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