Что возвратиться из неудавшегося метода и когда бросить?

Это зависит от того, что Вы подразумеваете под 'отказом'.

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

Если 'отказ' будет состоять в том, что никакие объекты не могли быть найдены для данного значения параметра, то я возвращу пустой Список. В случае, если Вы возвратили бы объект, который не является набором, я возвратил бы пустой указатель.

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

Если бы существует ожидаемый исключительный случай, я выдал бы исключение.

Если я искал Bar и не нашел его, я возвращу пустой указатель.

Если я искал List<Bar> и не нашел никого, я возвращу пустое List<Bar>.

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

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

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

1. пустой тип возврата как: новый Список; или: новый EmptyBar ();

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

3. выдайте исключение

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

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

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

Если нет никаких найденных элементов, возвратите пустой список. Это - особый случай шаблона Несуществующего объекта. Это помогает рассматривать все случаи последовательно, означая, что клиенты не должны будут проверять, является ли значение нулевым. Или хуже, если они не проверяют, Исключение нулевого указателя брошено и счастливая отладка для обнаружения, какова причина. Только возвратите пустой указатель, если у Вас есть очень серьезное основание для него.

Обновление: Martin Fowler описывает лучшую альтернативу возврату пустого указателя: http://martinfowler.com/eaaCatalog/specialCase.html

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

Там arw два вопроса ответить здесь:

• Концептуально отличается отказ функции от регулярного выполнения с пустым результатом? Вызывающая сторона могла реалистично должна быть знать, какой из этих случаев произошел? Если так, возврат пустого списка не является опцией. Я предполагаю в теории, Вы могли возвратить "специальный" пустой список, но это - путаница.
• Если функция перестала работать, кто должен будет обычно реагировать? Если это не сразу код вызова, но что-то выше, Исключением является самое чистое решение.

Если Ваша бизнес-логика может варьироваться в зависимости от того, что возвращает Метод, и таким образом нормально к Вашему Методу возвращаться, пустой список затем идут с 1).

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

Никогда не идите с 4), будет очень трудно понять это поведение позже.

Случай 1:

Если Метод, встретится с проблемой, которая делает то не ожидается, он должен выдать исключение. Код вызова должен заботиться об Исключении

Случай 2:

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

Не уверенный, если они могут быть универсально применены, но я довольно доволен следующими правилами:

1. Если названием метода является DoFoo, оно должно бросить, если это не может сделать Foo по некоторым причинам: сетевой ресурс недоступен, делание Foo не поддерживается этой конкретной реализацией интерфейса, объект находится в непоследовательном состоянии и т.д.
2. Если названием метода является GetBar, существует еще одна опция: возврат пустого указателя. Но лучше отразить это путем именования его как TryGetBar, GetBarOrNull и т.д. Конечно, пустое возвращаемое значение должно указать на что-то специальное и быть ответом на каждое исключительное условие.