Когда это плохая форма для возврата отложенного IEnumerable <T>

Мне любопытно, есть ли у кого-нибудь какие-либо правила или лучшие практики, когда имеет смысл вернуть отложенный IEnumerable<T> или вызвать ToArray() на нем, прежде чем возвращать его из функции.

Например, как потребитель API, я считаю, что для метода, такого как IEnumerable<Widget> GetWidgets(), я бы предпочел бы выбросить HttpException, когда я его вызову, и не заставлять его бросать, когда я перечисляю результаты.

public IEnumerable<Widget> GetWidgets(IEnumarable<int> widgetIds) {
    return widgetIds.Select(id => GetWidgetFromWidgetWebService(id));
}

Ответы

Ответ 1

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

Однако, если вычисляемый счетчик вычисляется и т.д., я обычно откладываю его.

Ответ 2

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

В конце концов, метод не заполнил то, что объявляет его название, поэтому он должен бросить.

Я обычно изменяю тип возврата на IList<T> в таких случаях, чтобы документировать, что он выполняется с нетерпением.