Возможно, что-то типа поставить redis под убунту: https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-redis-on-ubuntu-16-04

Ну это понятно, собрать из сорцов. Но при чем тут пакеты дистра ?

Ребят, а это нормально что работадатель указывает в вакансии PHP разработчика пункт: - Cборки и компиляция пакетов под Linux. ?

а где тут что про distr?

Ребят, а это нормально что работадатель указывает в вакансии PHP разработчика пункт: - Cборки и компиляция пакетов под Linux. ?

Вот тут пакет, для меня это пакет дистра.

или что под "дистра(ой)" имелось в виду?)

или что под "дистра(ой)" имелось в виду?)

дистрибутив линукса.

Со своим пакетным менеджером.

https://www.ubuntu.com/download ?

например как этот?

Ну это понятно, собрать из сорцов. Но при чем тут пакеты дистра ?

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

в нем apt менеджер есть

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

Ну я не спорю, что удобно. Я больше про то, а насколько это правильно в вакансии PHP. Если это норм, то ок.

Ну я не спорю, что удобно. Я больше про то, а насколько это правильно в вакансии PHP. Если это норм, то ок.

Может у них специфика такая? Чё гадать-то, спроси.

В таких ситуациях, в большинстве случаев помогает гугл, если в иксах не полный ноль.

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

В таких ситуациях, в большинстве случаев помогает гугл, если в иксах не полный ноль.

+. Если нужно чтото установить не совсем уж экзотическое - в гугле можно найти мануал как это сделать. Я в принципе, только так и умею собирать пакеты :) Да и не нужно мне запоминать детали, мне проще загуглить, когда требуется. А требуется не так часто, по крайней мере пока не сталкивался с такой необходимостью

т.е. тут имхо больше про наличие опыта, потому как иногда не все как в мануале идет :)

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

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

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

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

Вечер добрый, скажите пожалуйста ,как задокументировать, что то динамическое выкидывает ексепшен внутри метода? /** @throws AssertionFailedException */ $this->commandBus->dispatch( Так как команды разные, то и ексепшены внутри их могут быть разные, однако рнрstorm не видит этого и при попытке поймать ексепшен говорит что Exception 'AssertionFailedException' is never thrown in the corresponding try block less... (Ctrl+F1 Alt+T) The inspection reports catch clauses with exceptions which are never thrown from the corresponding try block.

Вечер добрый, скажите пожалуйста ,как задокументировать, что то динамическое выкидывает ексепшен внутри метода? /** @throws AssertionFailedException */ $this->commandBus->dispatch( Так как команды разные, то и ексепшены внутри их могут быть разные, однако рнрstorm не видит этого и при попытке поймать ексепшен говорит что Exception 'AssertionFailedException' is never thrown in the corresponding try block less... (Ctrl+F1 Alt+T) The inspection reports catch clauses with exceptions which are never thrown from the corresponding try block.

Можно указать родительский exception

В данном пакете есть магия

protected static function createException($value, $message, $code, $propertyPath = null, array $constraints = array()) { $exceptionClass = static::$exceptionClass; return new $exceptionClass($message, $code, $propertyPath, $value, $constraints); }

Хотя вот нашел родительский

Ексепшен

class InvalidArgumentException extends \InvalidArgumentException implements AssertionFailedException

Он уже казан в док блоке выше к методу

* @throws \Assert\InvalidArgumentException

И все равно рнрstorm говорит что ексепшен AssertionFailedException нигде не создан.

* @throws \InvalidArgumentException тоже не работает

Вечер добрый, скажите пожалуйста ,как задокументировать, что то динамическое выкидывает ексепшен внутри метода? /** @throws AssertionFailedException */ $this->commandBus->dispatch( Так как команды разные, то и ексепшены внутри их могут быть разные, однако рнрstorm не видит этого и при попытке поймать ексепшен говорит что Exception 'AssertionFailedException' is never thrown in the corresponding try block less... (Ctrl+F1 Alt+T) The inspection reports catch clauses with exceptions which are never thrown from the corresponding try block.

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

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

или писать \Throwable

Ну, раз уж пошла пляска про исключения - какие exception вы документируете в докблоках? Все? Как насчет Runtime исключений? Logic исключений? Видел мнение, что, так как Logic исключения - это ошибка в самом коде, какая-то в недоработка в логике, их нужно по-тихому залогировать, но не документировать, так как они не являются частью ожидаемого потока выполнения программы. То есть если существуют какие-то недоработки в коде, то их нужно залогировать и исправить, а не документировать

по работе с исключениями не плохо в java принято

есть 2 типа исключений отлавливаемые и нет (типо рантайм)

так вот за теми которые надо отлавливать прямо компилятор следит но компилятора в пхп нет поэтому тут карта ляжет

Ну, раз уж пошла пляска про исключения - какие exception вы документируете в докблоках? Все? Как насчет Runtime исключений? Logic исключений? Видел мнение, что, так как Logic исключения - это ошибка в самом коде, какая-то в недоработка в логике, их нужно по-тихому залогировать, но не документировать, так как они не являются частью ожидаемого потока выполнения программы. То есть если существуют какие-то недоработки в коде, то их нужно залогировать и исправить, а не документировать

а как быть с InvalidArgumentException ? он ведь extends LogicException

или например FileNotFoundException extends InvalidArgumentException ведь о наличие или отсутсвия файла можно узнать в рантайме

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

но при этом это все от LogicException идет

Очевидно, FileNotFoundException не должен экстендить InvalidArgumentException. Далее - если InvalidArgumentException extends LogicException , то его тоже логировать не стоит. Далее - если же речь идет о несоответствии значений чего-либо ожидаемому, стоит использовать UnexpectedValueException extends RuntimeException Пример из документации PHP http://php.net/manual/en/class.invalidargumentexception.php - The InvalidArgumentException class. Exception thrown if an argument is not of the expected type. Если мы ожидаем аргумент одного типа (речь необязательно о встроенном типе данных), а приходит другой - это ошибка логики программы. Мы её по-тихому логируем и исправляем, это не должна быть часть обычного потока выполнения, который мы должны документировать. http://php.net/manual/en/class.unexpectedvalueexception.php Exception thrown if a value does not match with a set of values. Typically this happens when a function calls another function and expects the return value to be of a certain type or value not including arithmetic or buffer related errors. То есть проблема уже не с типом, а со значением. Это рантайм ошибка, её появление является частью логики программы. Логируем, возможно, возвращаем посетителю, документируем в докблоке. В чем я неправ?

Очевидно, FileNotFoundException не должен экстендить InvalidArgumentException. Далее - если InvalidArgumentException extends LogicException , то его тоже логировать не стоит. Далее - если же речь идет о несоответствии значений чего-либо ожидаемому, стоит использовать UnexpectedValueException extends RuntimeException Пример из документации PHP http://php.net/manual/en/class.invalidargumentexception.php - The InvalidArgumentException class. Exception thrown if an argument is not of the expected type. Если мы ожидаем аргумент одного типа (речь необязательно о встроенном типе данных), а приходит другой - это ошибка логики программы. Мы её по-тихому логируем и исправляем, это не должна быть часть обычного потока выполнения, который мы должны документировать. http://php.net/manual/en/class.unexpectedvalueexception.php Exception thrown if a value does not match with a set of values. Typically this happens when a function calls another function and expects the return value to be of a certain type or value not including arithmetic or buffer related errors. То есть проблема уже не с типом, а со значением. Это рантайм ошибка, её появление является частью логики программы. Логируем, возможно, возвращаем посетителю, документируем в докблоке. В чем я неправ?

FileNotFound это опять же пример если мы ожидаем аргумент string пришел string но в текущем окружение этого файла нет или прав недостаточно на его чтение это FileNotFoundException ок ненаследуемся мы от InvalidArgumentException то в каких случаях он будет вообще вылетать ? https://3v4l.org/Jrv78 тут TypeError а не InvalidArgumentException, в каком случае по вашим словам должен возникать InvalidArgumentException ? "это не должна быть часть обычного потока выполнения" исключение это как раз таки способ сообщить что то внезапно не так и мы не знаем как с этим поступить, а вот как обрабатывать каждое исключение вопрос открытый и сильно зависит от конкретной ситуации

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

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

У вас есть универсальный гидратор. Ожидаемый тип объекта задается динамически. Значит, декларацией типов значения не проверить. Как такой вариант применения для InvalidArgumentException?

У вас есть универсальный гидратор. Ожидаемый тип объекта задается динамически. Значит, декларацией типов значения не проверить. Как такой вариант применения для InvalidArgumentException?

если он универсален значит он работает от того значения что ему переданно, разве нет ?

вот пример InvalidArgumentException о котором вы говорите, но его описывают в Throws https://github.com/PHP-DI/PHP-DI/blob/master/src/Container.php#L121

а вот исключения возникающие в Runtime да возможно стоит делать как в java и не описывать я все таки в этом вопросе склонен довериться опыту java потому что это тонка грань это чисто мое имхо, а LogicException мне кажется стоит описывать в блоке throws и писать что именно не так как в ссылке с примером. и возможно даже phpstorm не просит вылавливать или документировать RuntimeException (доп ургумент) а раз так делают большинство, то код будет более привычен большинству

если он универсален значит он работает от того значения что ему переданно, разве нет ?

Могут быть несоответствия типов создаваемого объекта и полученных данных. Содержимое массива и т.д. То, что не всегда можно проверить декларацией типов. Согласен насчет тонкой грани - поэтому и был задан вопрос. И ещё нужно решить, для чего же тогда UnexpectedValueException :)

ну тут описание вполне божественно http://php.net/manual/en/class.unexpectedvalueexception.php это когда вызвал другую функцию а она вернуло что то внезапно другое)))

вот пример InvalidArgumentException о котором вы говорите, но его описывают в Throws https://github.com/PHP-DI/PHP-DI/blob/master/src/Container.php#L121

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

а вот исключения возникающие в Runtime да возможно стоит делать как в java и не описывать я все таки в этом вопросе склонен довериться опыту java потому что это тонка грань это чисто мое имхо, а LogicException мне кажется стоит описывать в блоке throws и писать что именно не так как в ссылке с примером. и возможно даже phpstorm не просит вылавливать или документировать RuntimeException (доп ургумент) а раз так делают большинство, то код будет более привычен большинству

все исключения возникают в рантайме

все исключения возникают в рантайме

Логично :D

все исключения возникают в рантайме

поэтому в java есть еще те что возникают на компиляции )) но да это не та комната для обсуждения

https://github.com/symfony/symfony/pull/22231 что об этом скажете?

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

https://www.tutorialspoint.com/java/images/exceptions1.jpg

по psr <?= это хорошо или плохо ?

нашел в psr-1 , это н ормально

По ссылке: It's not a lack of interest in a complete contract, it's that it's different contracts for different targets. A \RuntimeException is for the application, which may handle it whereas \LogicException is for you as a developer. Ensuring that you don't get a \LogicException when running your application in production is your responsibility.

По ссылке: It's not a lack of interest in a complete contract, it's that it's different contracts for different targets. A \RuntimeException is for the application, which may handle it whereas \LogicException is for you as a developer. Ensuring that you don't get a \LogicException when running your application in production is your responsibility.

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

https://github.com/symfony/symfony/pull/22231#issuecomment-296229530 ссылка на коммент

а ну это чьето имхо

а ну это чьето имхо

Любое мнение - это чье-то имхо. Просто к некоторым прислушиваются, они даже чатики в телеграме открывают :D

Это субъективное мнение каждого. Имхо для ленивцев

ERROR: S client not available

Любое мнение - это чье-то имхо. Просто к некоторым прислушиваются, они даже чатики в телеграме открывают :D

просто я думал мб в доках где то на php.net такое написано

и я такое пропустил при прочтение

Котаны. А подкиньте плиз ссылочки на либы для промизов. Что я вообще нашёл: 1) React - тру, но есть баги, не прокидываются исключения наружу (https://github.com/reactphp/promise/issues/128) 2) Amp - монстр. 3) Kraken - мёртвый 4) Guzzle - пока единственный вариант походу. Сейчас буду на посмотреть. Мб ещё есть что?

с газзлом такая же фигня

=\

мб это я дурак?

Пишу: $p = new Promise(); $p->then(function($v) { throw new \Exception('Example'); }); $p->resolve(23); И необработанное исключение тупо гасится, а не прокидывается наверх

Я думаю что их нужно отлавливать на otherwise https://github.com/reactphp/promise#promiseinterfaceotherwise

@ball00n можно

но я не могу

точнее не так, у меня один обработчик исключений

и для каждого промиза его присобачивать - проще убиться

промисы чейнится должны вроде бы

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

т.е. и в реакте, и в газзле баги

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

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

ну напиши в консольке

let p = new Promise((c) => { setTimeout(() => c(), 1000); }); p.then(() => { throw new Error(); });

увидишь исключение

а теперь на газельке

$p = new Promise(); $p->then(function(): void { throw new \Exception('Example'); }); $p->resolve(23);

консоль пустая

пример с реактом выше по ссылке в иссью

ну т.е. тут не в неправильности использования, а в том, что реализация некорректная

чейни промисы и все будет ок

да не могу я чейнить же

ну т.е. могу, конечно

консоль пустая

потому что надо сделать catch?

но код превратится в люты треш

но код превратится в люты треш

хочешь хорошо - делай хорошо

@fes0r если не делать кетч, то оно рендерится)