gzhegow
@gzhegow
aka "ОбнимиБизнесмена"

Что удобнее, тем, кто уже пробовал — Передавать ошибку return или сразу бросать Exception прямо из функции/foreach?

Что удобнее, тем, кто уже пробовал - Передавать ошибку return или сразу бросать Exception прямо из функции/foreach?
  • Вопрос задан
  • 293 просмотра
Решения вопроса 3
DevMan
@DevMan
зависит от архитектуры. мне удобнее сразу райзить эксепшен.
Ответ написан
lxsmkv
@lxsmkv
Test automation engineer
Через return можно возвращать код ошибки и собирать ошибки этажом выше а потом что то делать в зависимости от того какие ошибки были получены. В тестировании например может иметь место такой подход. Потому что эксепшн сразу прервет выполнение теста. А это может быть не желательно в конкретном случае. Зависит как уже сказали от архитектуры.

Вот ещё, недавно наткнулся:
https://habrahabr.ru/company/mailru/blog/322804/ - Выбор правильной стратегии обработки ошибок (части 3 и 4)
Ответ написан
gzhegow
@gzhegow Автор вопроса
aka "ОбнимиБизнесмена"
На текущий момент мой ответ изменился, когда я закончил работу с пачкой поставщиков и постоянно меняющимися условиями - сегодня по цене, потом по сортировки, завтра еще по чем...
1. Не использовать for {}, если есть map()
2. В map возвращать array(1,msg,data)
3. Если map вложенный или родительский - в ответ отправляется data, а ошибки собираются в err[]

Таким образом где-то так:
function mapfunc($item) {
  return array(null, null, array(
    "stdout" => $item,
    "stderr" => $foobar,
    )
  );
}


Это в соответствии с договоренностью о возврате массива array(errcode, msg, data).
По итогу после map() для какой-то коллекции на выходе получим коллекцию из отчетов.

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

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

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

Это примерно как концепция отдельного процесса, когда у него есть поток вывода сервисный, для ошибок, а есть поток вывода пользовательский - для результата.

Такой подход будет универсальным и для работы с ajax запросами, и для работы с коллекциями, и при загрузке в базу данных поочередно, и для очередей запросов - очень удобно, если освоить функцию типа _pluck, чтобы быстро отделять данные от отчетов.

Но особо упертые могут делать два разных map() - один для отчетов по ошибкам, другой - с заглушенными ошибками и просто для данных - на выходе получится массив из null и корректных данных.

Отдельная реализация может быть даже такая:
$rep = array();
$data = array_map(function ($row) use (&$rep) {
  $bad = false;
  if ($bad):
    $rep["bad"] = array(1, "msg", array("foo" => $foo, "bar" => $bar));
    return null;
  else:
    $rep["good"] = array(null, "OK", array("foo" => $foo, "bar" => $bar));
    return $row;
  endif;
});


Это все к тому, что ХОРОШЕЕ приложение - НЕ ИМЕЕТ ошибок. А с точки зрения логики приложение НЕ МОЖЕТ не иметь ошибок, поскольку нельзя гарантировать идеально правильного человека. Смысл ошибки сводится в конечном итоге к вине пользователя. Если пользователь сотворил беду и сам хочет ошибку - он должен ее получить, а если он ничего не делал толком, а ошибка произошла - то ее не должно было произойти.

Но показывать то их нельзя, поэтому для главного модуля это warning, а для конечного этапа это exception. А ошибка одна и та же.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 4
BacCM
@BacCM
C++ почти с рождения
Как уже писали зависит от архитектуры.
Но самое главное чтобы было однообразие подхода и не было мешанины

Чисто субъективно мне больше по душе возвраты ошибок через return. И причин тому несколько.
Не все компиляторы легко переваривают исключения, да в 2017 году! Например для встраиваемых систем для DSP вообще много где рекомендуется чистый C. И включение поддержки исключений и rtti не рекомендовано.
Ответ написан
@d-stream
Готовые решения - не подаю, но...
Принципиально зависит от того что требуется.

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

Главное помнить про цену

Ну и да, одно из принципиальных отличий:

возврат через return - это возврат на один уровень, а exception - на любое кол-во уровней.

т.е. при сотне вложенных вызовов exception, если нет например try-catch вызовет мгновенную телепортацию вплоть до операционной системы
Ответ написан
dmitriylanets
@dmitriylanets
веб-разработчик
выбросить Exception, если в дальнейшее выполнение функции не возможно
выбросив Exception вы можете обработать ошибку в зависимости от того где вы будите использовать функционал.
Ответ написан
@leremin
atypical programmer
Например, в C# сплошь и рядом исключения, а в Qt их нет совсем. То есть оба принципа имеют право на существование. А по делу наберите в поисковике "хабр исключения или коды возврата" и почитайте статьи и комментарии к ним. Их там десятки статей и сотни тысячи комментариев.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
11 мая 2024, в 00:19
1000 руб./за проект
10 мая 2024, в 23:51
30000 руб./за проект
10 мая 2024, в 23:33
2500 руб./за проект