зато мы не обрабатываем результаты вызовов

но мы сделали первый if для типа исключения, второй if чтобы понять а кто его реально выкинул

наверно поэтому в яндекс кассе любая ошибка это Упс что то пошло не так )))))

Нахер жить без исключений) пущай всякие голанги лапшекод требуют)

ну вывести упс это одно

надо ее еще корректно залогировать чтобы потом исправить

какая разница кто его выкинул

какая разница кто его выкинул

Во-во)

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

+ исключений в том что я могу просто прокидывать их на урвоень выше

какая разница кто его выкинул

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

в другом нет

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

Типы в помощь

+ исключений в том что я могу просто прокидывать их на урвоень выше

goto тоже может на уровень вверх кидать )

Типы в помощь

я уже писал о типах выше

как о одном из решений

но это плодит лишний класс

и именно так сейчас и решеют проблему

лишний класс!!!

но я написал о ситуации когда 2 функции могут выкинуть именно исключение одного базового типа, InvalidArgumentException или RuntimeException

goto тоже может на уровень вверх кидать )

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

Притягиваешь проблему за уши

лишний класс!!!

дело не в экономии на списчка а в том что это усложнение кода

который может усложнить и увеличить в размерах по

у меня класс исключения создается на каждую команду

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

или сразу вернуть ошибку нужного типа

Расскажи это любителям обмазаться голангом. Реально, нахер так жить?)

и не париться с ее обработкой и формированием уровнем выше

Расскажи это любителям обмазаться голангом. Реально, нахер так жить?)

существует много языков без исключений

причем языков на которых базируется огромное количество кода

или сразу вернуть ошибку нужного типа

кому вернуть?

и разработанного по которое работает

и потом через 10 функций ее прокидывать?

кому вернуть?

почитай про either как коняш написал для примера

и разработанного по которое работает

это самый неудачный аргумент

Хз чем проще без исключений. Сплошная жопоболь

почитай про either как коняш написал для примера

мне не оч нравится такой подход

никто не говорит что надо писать без исключений

но надо учитывать и другие практики

у нас был на преокте судя по гит блейму фанат такого кода

class DummyEntityProvider extends DataEntityProvider { public function initialize(array $data = []) { } /** * @return array|bool */ protected function provideNextData() { return false; } }

и знать и возможно иногда они более удобные

class DummyEntityProvider extends DataEntityProvider { public function initialize(array $data = []) { } /** * @return array|bool */ protected function provideNextData() { return false; } }

?? 2009

ну можно писать хипстерский код 2018 только в пхп хипстоты мало

и исключения придуманы далеко не в 2009 году

поэтому 2009 год тоже как то не уместно

class DummyEntityProvider extends DataEntityProvider { public function initialize(array $data = []) { } /** * @return array|bool */ protected function provideNextData() { return false; } }

Ну, намана if (!$variable) { } // if (isset($variable['error'])) { } Каеф же

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

https://refactoring.guru/ru/replace-error-code-with-exception

https://refactoring.guru/ru/replace-error-code-with-exception

Обработку исключений можно превратить в goto-подобный костыль. Не делайте так! Не используйте исключения для управления исполнением кода. Исключения следует выбрасывать только в целях сообщения об ошибке или критической ситуации.

читай там ниже написано

да я читал эт

что исключение надо юзать в сообщениях об ошибке или критических ситуациях

а не для возврата результата из функции

но лучше исключения обрабатывать как можно раньше

Мне вот больше интересное другое Почему вы рассматриваете это с точки зрения языка с динамической типизацией?

там не слова нет про использование исключений для возврата из функций

а еще лучше не бросать)

class DummyEntityProvider extends DataEntityProvider { public function initialize(array $data = []) { } /** * @return array|bool */ protected function provideNextData() { return false; } }

В той же джаве ты не сможешь сделать вот это

что исключение надо юзать в сообщениях об ошибке или критических ситуациях

а что невозможность вернуть то что мне надо, не считается критической ситуацией?

В той же джаве ты не сможешь сделать вот это

верни Object и можешь

верни Object и можешь

Ну ты и падлюка...

вместо array|bool

а что невозможность вернуть то что мне надо, не считается критической ситуацией?

код не должен делать то что тебе надо

он должен делать то что он обещает сделать

если ты написал что вернешь результат то да он должен вернуть результат или крашиться

если ты написал что вернешь результат то да он должен вернуть результат или крашиться

да верно

а ты предлагаешь не крашитсья а вернуть false

но ты можешь написать что он вернет нечто с результатом и зависимости от ситуации решать продолжать ли дальше

а ты предлагаешь не крашитсья а вернуть false

где я такое предложил?

или еще хуже -замаскирвоанный нуллОбджект

нулл обджект это из другой песни

и частный случай maybe

а не either

когда надо просто возвращать нормально ответ и проверять его

вот

это не обязательно nullObject

и сам nullObject маскирует null

а не его маскируют

в качестве примера популярный пример это валидатор

кто то из умных дядек писал что валидатор не должен возвращать исключения довольно большие статьи и писал объяснения по этому поводу

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

не возвращать верней а выкидывать

в теории ты можешь и вернуть исключение через return а не выкинуть его через throw

точно также как и пример работы с фс и выкидывания исключений может в одной ситуации действительно требовать исключения

например нету файла sqlite.db

а в другой не выкидывать исключения и просто нету файла с сессии

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

а конкретно твой код

ну либо будет библиотека выкидывать кучу исключений ты будешь все их слушать (считай обрабатывать) и потом выкидывать свои исключения в случае необходимости

в теории ты можешь и вернуть исключение через return а не выкинуть его через throw

Код станет понятнее, да) По поводу умных дядек: высасывать проблему из пальца - это хорошо. Но бесполезно. Валидатор - 1 из немногих кейсов, которые требуют возврата результата только в силу специфики того, что негоже юзверю построчно ошибки вываливать. А все сразу лучше дать. И то это можно решить исключениями) и ни что, кроме времени больших дядек, не пострадает.

Код станет понятнее, да) По поводу умных дядек: высасывать проблему из пальца - это хорошо. Но бесполезно. Валидатор - 1 из немногих кейсов, которые требуют возврата результата только в силу специфики того, что негоже юзверю построчно ошибки вываливать. А все сразу лучше дать. И то это можно решить исключениями) и ни что, кроме времени больших дядек, не пострадает.

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

$error = new ValidationException; $error->add('invalid username'); $error->add('invvalid pet name')' throw $error;

Спасибо, кэп) я про сие написал в конце)

я видел и это не занимает много времени

суть не в том сколько времени

Имелось в виду время, потраченное на статьи :)