Дойдет ли до json_last_error, если json_decode выкинет ексепшен?

Question

[BonBon Slick]

public function convertJsonStringToArray(ControllerEvent $event): void {
        $request        = $event->getRequest();
        $requestContent = $request->getContent();
        // check if json and not empty content
        $isContentEmpty = true === empty($requestContent) || null === $requestContent || '' === trim($requestContent);
        if (true === $isContentEmpty || $request->getContentType() !== 'json') {
            return;
        }
        // check for errors
        $jsonContent = \json_decode($request->getContent(), true, 512, JSON_THROW_ON_ERROR);
        if (JSON_ERROR_NONE !== json_last_error()) {
            throw new BadRequestHttpException(sprintf('Invalid json body: %s', json_last_error_msg()));
        }

Comments

[FanatPHP]

не дойдет, разумеется

[FanatPHP]

код - кровь из глаз.

$isContentEmpty = true === empty($requestContent) || null === $requestContent || '' === trim($requestContent);

вместо
!trim($requestContent)
сразу видно "архитектора" - языка не знает, но количество умных слов на строчку кода зашкаливает :)

[BonBon Slick]

FanatPHP, лол
!trim($requestContent)
1 - не читабельно
2 - не понятно
3 - баговано и непредсказуемо

Ваш коментарий офтоп.

object calisthenics, дополнительные проверки не будут лишними.
И еще, видно же что код старый, ему 2 года. Автокомплит рекомендовал доставить , true, 512, JSON_THROW_ON_ERROR); вот и просил и все.
Как гуру девмен ниже написал, надо ловить ексепшен и выдавать свой. Его потом у меня ловит другой слушатель.

[FanatPHP]

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

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

[BonBon Slick]

FanatPHP, Это дело практики. Читабельно должно быть все, даже когда 1 значение и 1 строка.
В слушатель редко кто заглядывает, он работал и без модификации параметров декода.
На счет предсказуемости, я же даже код привел. В некоторых моментах работает не так как думаешь. И на счет лени, мозгу приходится больше тратить ресурсов на подумать.
В общем, все это оффтоп про методики, техники и предпочтения.
На результат доп проверки не повлияли. Обсуждать бессконечное количество возможных вариантов реализации смысла нет, трата времени.
А вопрос, как лучше и почему выполнять проверку, вызвал бы дискуссию и не более, такие вопросы удаляют тут в основном.

[FanatPHP]

На результат доп проверки не повлияли.

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

[FanatPHP]

в реальной жизни достаточно написать if(!trim($requestContent)) - этот код будет делать ровно то же самое что и твой развесистый операторточно так же не пропуская теоретически валидный ноль.
если же хочешь быть святее папы римского, то if (!strlen($requestContent))) - оно не пропустит пустую строку, пробелы, Null и false

Answer 1

[DevMan]

требовать исключения и не ловить его - это пять.
https://3v4l.org/sU3IN самому сложно, да? неужели проще задать вопрос, когда можно самому проверить буквально за секунды?

Comments

[FanatPHP]

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

[DevMan]

FanatPHP, а смысл требовать исключения и проверять по старинке?
ну и результат в примере.

[FanatPHP]

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

я кстати ступил, а ты все правильно написал.
если мы хотим вместо JsonException перевыкинуть BadRequestHttpException , то первое надо все-таки поймать
а проще всего не добавлять JSON_THROW_ON_ERROR, а оставить все как было

[DevMan]

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

function decodeJSON( $json ) {
    return json_decode( $json, true, 512, JSON_THROW_ON_ERROR );
}
.............
try {
    $jsonContent = decodeJSON( $request->getContent() );
} catch( JsonException $e ) {
    throw new BadRequestHttpException( 'Invalid json body: ' . $e->getMessage() );
}

[BonBon Slick]

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

[DevMan]

BonBon Slick, вопрос однозначно стоило задать иначе. но маємо шо маємо.

[DevMan]

BonBon Slick, у меня сложилось впечатление, что ты вроде не тупой (и это комплимент, а не оскорбление).
но некоторые твои вопросы (и конкретно этот), загоняют меня в тупик: ты рубишь в более сложных темах, но плывешь на элементарщине.

[BonBon Slick]

DevMan, мне часто лень думать. Я часто задаю вопрос и иду решаю другу задачу. Потому проверяю ответ, если устраивает, принимаю, если нет, вступаю в дискуссию и решаю сам. Как это был про валидацию с симфони. Мне честно пофиг если меня буду считать тупым, ведь так и есть сколько бы и каких вопросов не задавал.

[DevMan]

BonBon Slick, это реально печально.
именно не прием чужих ответов, а "мне часто лень думать".
а что если я в этом своем ответе насвистел? и на самом деле все не так и исключения работают иначе?

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

[BonBon Slick]

DevMan,

это реально печально.

. Стоит добавить, мне лень думать над мелкими деталями и их реализацией, в них я и так погряз и трачу большую часть времени разработки. Их реализацию и как правильно, это часто дает минимум прогресса к цели, плану.
Это я так, заглядывал в старый код, сейчас делаю RBAC нормальный, довольно затратно, синхронизировать надо Permission с Role и User.
User -> Role -> Permission -> User

Такой подход покрывает whitelist / blacklist и access controll deny / allow для feature / resource / module.
Role -> FeatureTag + User
Permission -> resource / route / url + urlRegExp + FeatureTag + Users + ActionType (EDIT, FILE_UPLOD, SERVER_EXEC, FOLDER_CREATE)
Это все пет проект, поетому делаю по мере того как обдумаю все, медленно.

Все ответы с которыми согласен проверяю.
Ведь пишу тесты на этот код и использую его.
Исключени бывают когда дают ответы на вопросы которые долго тестировать и, или где без разницы какой ответ, к примеру " laravel packages must have".
Так что если "свистуны", то это будет заметно.

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

Чего лукавить, согласен, виновен, был в трен зале и только вернулся. Там читал про enum в 8-ке, наконец-то занесли, лучшая новость за весь год. TS их использую постоянно. А то лепить костыли вроде , а константы приводят к ошибкам и надо лепить проверки

class A{
const Test_1 = 1;
const Test_2 = 2

const Tests = [self::Test_1, self::Test_2];

public function test(int $int) {
if (false === in_array(self::Tests, $int)){
return;
}
// do smth ...
}

}

$test = new A();
$test->test(1235);

Но полагаю вы за rfc следите и уже знаете об этом.

[DevMan]

BonBon Slick, угу, знаю. тащемта, они были доступны и раньше, хоть и не в ядре.

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

[FanatPHP]

В общем, клиент системы " я не тактик, я стратег" :)

[BonBon Slick]

FanatPHP, wiki or quora. Если вы очень "не ленивы", возможно вы переоцениваете себя и свои заняния, возможности что может придавать излишней уверенности, мотивации.

[FanatPHP]

да я уже понял, что ты за гусь :)
разберись сначала со своим "багованным и непредсказуемым" true === empty($requestContent), а потом приходи, перетрём за высокие материи

[BonBon Slick]

FanatPHP, ок ;)