Должна ли функция возвращать разные значения в случае ошибки и в случае если нет данн

[Фанат]

Должна ли функция возвращать разные значения в случае ошибки и в случае если нет данн

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

 

[akd]

ну дык, если допустимо что запрос не вернет ни одной строки, то это не ошибка

-~{}~ 01.06.10 19:29:

если надо примеров, у нас в системе есть метод, который возвращает данные операторов конкретного клиента .. так вот операторов у клиента может просто не быть.

 

[Single]

Сейчас она возвращает FALSE и при ошибке, и если запрос не вернул ни одной строки.

Для себя остановился на варианте если произошла ошибка при запросе к БД функция возвращает false, на нулевой ответ возвращает пустой массив.

 

[Adelf]

вариант с пустым массивом - более логичный.
Также логично было бы Exception при ошибке.

Хотя все от архитектуры зависит...

 

[Духовность™]

ООП

 

[Фанат]

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

 

[newARTix]

Если ошибка в запросе это штатное событие, то false. Ноль строк - это null (если ожидается скаляр) или пустой массив или пустая коллекция.

Если же ошибка в запросе это нештатное событие, то Exception.

я делаю так

 

[Духовность™]

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

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

mysql_num_rows() возвращает количество рядов результата запроса. Эта команда работает только с запросами SELECT. Чтобы получить количество рядов, обработанных функцями INSERT, UPDATE, DELETE, используйте функцию mysql_affected_rows().

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

 

[Фанат]

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

 

[iceman]

ООП - try-catch, программист сам определит как обработать исключение...

 

[fixxxer]

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

 

[grigori]

IMHO результат и статус - разные данные, и передавать их в одной переменной не стоит
лучше возвращать код статуса, а в параметре по ссылке - сам результат

я предпочитаю исключения как тип данных, созданный для ошибок, и способ их возврата

 

[Фанат]

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

 

[weregod]

имхо, ф-ция, которая может возвращать то скаляр, то массив, то булево значение, плохая
Adelf +1

 

[tenshi]

а что мешает писать так?

$res= $db->query( $query )
if( $res->error ):
    die(1);
else:
    var_dump( $res->value ); // если пустой ответ, то тут null
    var_dump( $res->rows ); // тут пустой массив
    var_dump( $res->cols ); // тут тоже
    var_dump( $res->table ); // аналогично
endif;

или

$value=  $db->query( $query )->value; // тут null в случае ошибки, или если null - значение поля.

-~{}~ 02.06.10 20:01:

хотим разделяем, не хотим - не разделяем. и всё на своих местах, а не вперемешку.

 

[Фанат]

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

 

[korchasa]

А в чем писанина то?

ИМХО:
- ошибки через исключения
- разделить функции на возвращающую скаляр, и возвращающую список

Клиентского кода станет сильно меньше, т.к. не надо будет проверять на ошибку и пустое значение.

 

[AmdY]

добавь необязательные поля, если нужно вернуть что-то отличное

$id = $this->getRequest()
                ->get(2, new Exception_Badparam('Не передан индефикатор пользователя'), Type::T_INTEGER);

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

только стоит шаги 2-3 поменять местами, наверное.

 

[Фанат]

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

А ошибки разделять - так в том-то и вопрос. Что с ними потом делать.
die(1) - это, извините, не наш метод.

Эх, никто не хочет помогать с реальными примерами, самому придется.

$data = $db->query(2,  "SELECT * FROM news WHERE id = %s", $GET['id']);
if ($data === false) errpage(500);
if (!$data) errpage(404);
include "shablon.php";

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

$num = $db->query(1,  "SELECT count(*) FROM online");
if (!$num) юзеров нет
else $num юзеров;

пока не придумывается.

-~{}~ 02.06.10 21:32:

Необязательные не могу - там и так параметры запроса лежат.

-~{}~ 02.06.10 21:50:

Exception_Badparam('Не передан индефикатор пользователя')

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

Короче, что-то я сам замудрился, похоже.

 

[AmdY]

эксепшин поднимается выше экшина, но обрабатывается в том же контроллере, получается 404-я + вывод страницы ошибки для данного контроллера с текстом ошибки. По идее такой ситуации в жизни не должно случаться, только если ручками пробуют или ссылка криво прописана.
Просто это стандартная ошибка и незачем городить код обработки в каждом экшине, тем более, что многие его просто забывают или ленятся писать