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

Чушь это - пытаться предусмотреть заранее всевозможные изменений требований.
Если по логике вещей программа должна возвращать bool (т.е. одну из альтернатив) - возвращай bool.
Если значений вроде может быть больше, хотя сейчас только 2 - то enum.
При нормальном имени функции и хорошем дизайне - изменить определение функции и ее использование - полчаса работы + сколько нужно для перекомпиляции проекта.
И вообще, нужно решать проблемы по мере поступления, а не пытаться общую теорию всего соорудить.
Что касается 3 последних вариантов - это просто абсурд и конец ООП.

в случае энама это 1 минута работы + сколько нужно для перекомпиляции проекта
но енамы плодить вредно, потому и опрос создал


интересно, чем 3й вариант не понравился... зачем же еще исключения?

Все уже придумано до нас 


З.Ы.: А ваще, прежде чем что-то писать, нужно хорошенько все продумать и алгоритм нарисовать на бумаге ( а лучше использовать UML ). Тогда такие споры и вопросы отпадут сами по себе

Исключения нужны для обработки нештатных ситуаций, возникающих  во время работы программы, а не во время разработки оттого что программист что-то забыл. Для того, чтобы чего-нибудь не забыть при изменениях, есть ASSERTы, времени выполнения или времени компиляции.
А насчет enum, когда по смыслу предполагается альтернатива... это все равно, что на вопрос, требующий четкого ответа да\нет отвечать "ну, вы понимаете, в некотором смысле, если конечно, ..."

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

возврат bool или enum - это абсолютно разная семантика, если ф-я должна ответить на простой вопрос - да или нет, то - bool -если ответить на более сложный (например описать состояние объекта, который на данном этапе может быть в 2х состояниях, но потом их может прибавица) - тогда enum.))

спецально для идеалистов. Ситуация:

есть функция, которая делает импорт файла. возвращает bool - сделала или нет

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

Кто виноват? Ведь разработчик свою задачу сделал - написал функцию, которая возвращает даже, получилось ли импортировать файл.
Что делать? Вариант с throw не подходит, так как это не ошибка, да и заставлять дописывать везде try catch нет желания


Тут волей-неволей даже о 4м варианте задумаешься...

Это сообщение отредактировал(а) Alek86 - 22.2.2008, 15:42

Alek86, это очень специфический пример. Полагаю, что возможность прерывания составной операции будет реализована через Thread-ы c событиями. Если так, то наша BOOL Name (/* arguments */) уходит глубоко в пучину вызовов, а точкой доступа для пользователя будет какая-то новая обёрточная функция, заключающая в себе весь новоиспечённый механизм. То есть, была функция - понадобилось её расширить, не трогая её кода - сделали обёртку-фасад. И дело с концом. В более простых случаях Name может даже заинлайнится.

нужно использовать исключение

а для этого должна быть такая-же функция но делающая импорт по чуть-чуть... возвращаемое значение у нее скоре всего будет говорить закончила она работу, или ее еще раз нужно вызвать...
что-то вроде:

тут наоборот: понадобилось изменить код - пожалуйста.
А трогать "интерфейс" - ох как больно...


1. получается, что в библиотечных функциях лучше bool не возвращать. Ибо потом скажется. И чем это "потом" будет позднее, тем хуже.
2. второй вариант плох только тем, что плодит лишние типы? или есть что-то, чего я не заметил?
3. еще интересно услышать, как определить, будет функция возвращать "одну из 2х альтернатив" или "одну из n альтернатив"?

ну и работать весь этот огород должен в соседнем потоке))

Lazin, не совсем так.
та библиотечная функция теперь и должна реализовывать такое поведение
а вот изменение интерфейса (и очень много перекомпиляции) как раз из-за того, что разработчик посчитал:




можно подробней? где именно?

вот здесь

если не сделала, значит исключение - ошибка импорта


разработчик правильно посчитал, функция в первом случае(делает весь импорт сразу) и во втором(делает импорт по частям), имеют разную семантику, они не могут вызываться одинаково, и не могут быть заменены одна на другую. Здесь возвращаемое значение вообще не причем.
а сделал-бы я так:

Мне кажется речь  о том чтобы а) сделать ф-цию myCoolLibraryFunctionEx которая возвращает enum б) реализовать ф-цию myCoolLibraryFunction примерно как

в) наслаждаться жизнью без перекомпиляции проектов.

Ой ли?
 
на что тут boolean заменять? FileNotFound добавлять?

Alek86, ну а не надо трогать интерфейс! Пусть себе живёт простая и счастливая bool Name() в том виде, как она сделана - без турбо-двигателя, нитро и спойлеров. А новый фасад, может, будет реализовывать расширенный или совсем другой интерфейс на её основе. Вам же проще будет. И почему никому не пришло в голову char и wchar_t сварить некоторое квази-общее представление, так сказать РАСШИРИТЬ char до wchar_t..?  Вместо этого многие системные вызовы существуют в двух вариантах - с постфиксами A и W.