gzhegow
@gzhegow
Думал, стану умнее, когда адаптируюсь, но нет

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

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

Вот ещё, недавно наткнулся:
https://habrahabr.ru/company/mailru/blog/322804/ - Выбор правильной стратегии обработки ошибок (части 3 и 4)
Ответ написан
gzhegow
@gzhegow Автор вопроса
Думал, стану умнее, когда адаптируюсь, но нет
На текущий момент мой ответ изменился, когда я закончил работу с пачкой поставщиков и постоянно меняющимися условиями - сегодня по цене, потом по сортировки, завтра еще по чем...
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 их нет совсем. То есть оба принципа имеют право на существование. А по делу наберите в поисковике "хабр исключения или коды возврата" и почитайте статьи и комментарии к ним. Их там десятки статей и сотни тысячи комментариев.
Ответ написан
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы