Неа, я дождался компилляции и тем не менее получаю краш с последующим возможным зависанием пк при каждой смене локации. Плюс фпс забавно может с 50-55 просесть до 20, при этом сильно растет потребление оперативки и видеопамяти. Помогает понижение качества текстур, но ненадолго. Подозреваю, что источник утечек памяти не только в упомянутой библиотеке, так как 8 гигов видеопамяти и 32 гига оперативы съедаются очень быстро
Вы смотрите на вещи очень буквально, и никак не можете абстрагироваться от прямолинейного отношения к исключениям, как к банальным ошибкам.
Вы совершаете типичную ошибку: исключения != ошибка. В php к сожалению разница между Exception и Error условная. Но в других языках это не так. Именно ошибки ловить не стоит, а в других языках это вообще невозможно, потому что они действительно нужны чтобы просто уронить программу, но речь то про исключения, а исключения != ошибки. Вы же их мешаете в своих утверждениях. Пример исключения: передача 0 в делитель, потому что операция деления принимает 2 числовых операнда, но есть 1 случай, когда деление не сработает. Пример ошибки: передача строки в операцию деления, потому что деление работает только с числами. То, что php позволяет ловить и ошибки, и исключения - это, имхо, большое упущение, поэтому надеяться можно только на линтеры и code review.
Он ничем не отличается от любого другого случая выброса исключения.
Он отличается тем, о чем я вам твержу уже несколько комментариев: это случай, когда у вас нет глобального обработчика исключений
Исключение тем и отличается от возврата, что поймать его можно где угодно.
Опять же, разница исключений и ошибок: исключения стоит ловить сразу. Зачем мне на уровне контроллера оборачивать метод, в котором через несколько слоев есть вызов метода из доменного слоя, в котором есть деление и потенциально там может быть деление на 0? Нет, надо ловить исключение сразу. При чем возможно ловить его в самом доменном слое, а затем оборачивать в исключения доменного уровня.
Если прямо в браузер кидается ошибка, то это значит, что на сервере криво настроено отображение ошибок.
Опять же путаются исключения с ошибками. Я не знаю, что у вас за принципы, но даже если настроить отображение ошибок правильно, то вы просто ошибку замаскируете под статус код 500, чего пользователь в нормальном сервисе видеть никогда не должен.
Смотрите на исключения не как на банальные ошибки
В том то и дело, что как на ошибки смотрите на исключения вы. Вы же их мешаете в своих утверждениях, хотя это разные вещи, пусть и технически в php они практически не отличаются
С этим прекрасно справляется централизованный обработчик ошибок
Для того, чтобы у вас был централизованный обработчик ошибок, вы должны написать его или воспользоваться готовым решением. Возможно я открою вам тайну, но симфони позволяет выкидывать ненужные компоненты
Нас не интересует случай автора.
С него все и началось, поэтому глупо от него отмахиваться. Такое ощущение, что вам просто не хватит аргументов, чтобы поспорить с тем, что данные пример - наглядное доказательство того, о чем я говорю
бросок исключения не завязан на его обработку
Какая глупость... Да будет вам известно, что исключение - это такой же легальный возврат из функции, как и return. Бывают случаи, когда вам возвращаемое значение из функции не нужно, но таких случаев единицы. Если исключение кидать, если его не надо обрабатывать или случаев, когда его надо обработать очень мало? Проще уже самому исключительные случаи предусмотреть и не кидать исключение. Наверное его кидают, потому что вариантов обработки, как и случаев, когда это действительно нужно много, и проще отдать это на усмотрение пользователю. С исключениями то же самое, что и возвращаемым значением: в единицах случаев нам надо не ловить исключение, чтобы уронить скрипт. В чуть большем количестве случаев можно обойтись глобальным перехватчиком. В остальных случаях нам почти всегда исключения надо ловить и правильно обрабатывать. Может не прямо в месте вызова функции, а на несколько уровней выше, но ловить надо, иначе у вас будут странности, типа того, что я порой вижу как на некоторых сайтах с упавшей базой прямо в браузер кидается PDOException
По поводу "моего" решения. Я не настаиваю, что оно лучшее. Это просто один из примеров того, что механического натыкивания try-catch и ручной конвертации исключений можно вполне избежать.
Такое решение не должно быть в пользовательском коде, потому что вы решаете простую задачу сложным путем. Помимо этого магия с атрибутами и рефлексией... Вместо слов, стоит процитировать 2 поговорки из Zen of Go: Clear is better then clever, Reflection is never clear. Максимально тупое, в хорошем смысле, решение всегда выигрышнее: оно понятно любому джуну, и вам не нужно будет тратить часы на объяснение того, каким образом работает решение подобно вашему. С более опытными разработчиками вы тоже потратите часы, но на объяснение причины того, почему так
@FanatPHP Во-первых, по поводу исключений с ошибкой валидаций: laravel кидает исключение, ктторое мапится на 429 уод http при ошибке валидации. Это норма.
Во-вторых, по поводу стек трейсов, логирования итп. Лично ВАМ этого делать не надо, потому что используя фреймворк, кто-то за ВАС уже это сделал. Это не значит, что теперь вам об исключениях не надо заботиться. Как только вы изолируетесь от фреймворков, или используете минималистичные фреймворки, это становится ВАШЕЙ проблемой. Это как раз случай автора.
В-третьих, по поводу вашего решения. У меня при прочтении возникало только одно слово в голове: "зачем?!"(в оригинале грубее). Вы напрочь игнорируете принцип KISS, и вы напрочь игнорируете существующие решения. Ваше решение в отличии даже от первого варианта выглядит проигрышнее по 2ум причинам: 1) ваше решение актуально только для симфони, в то время как первое решение с обычным try с несколькими блоками catch работает везде и всегда 2) первое решение максимально простое, если не сказать что тупое, его поймет любой джун. Но если вас смущает, что в блоках catch почти одинаковый код, то для вас есть простое решение: из вашего решения выкидываете все, кроме интерфейса StatusCodeProvider, наследуете его от Throwable, что автоматически обяжет пользовательское исключение наследовать Exception или Error, а затем вместо нескольких catch блоков использовать один, который ловит StatusCodeProvider. Это если придумываете велосипед. В симфони просто реализуйте интерфейс HttpExceptionInterface, остальное за вас сделает фреймворк. К чему эта магия с глобальным перехватчиком ивентов симфони, рефлексией и атрибутами? Это называется Overengineered garbage code: вы решаете очень простую задачу каким-то хитровыдуманным способом. Нафига?! Вы любите острые ощущения в продакшене?
Исключения действительно нужны для чистоты кода, но ваше решение - это прямая противоположность чистоте кода. Чистый код в первую очередь - это понятный каждому код, выполняющий четко свою задачу. Для простой задачи вы придумываете магическое решение, которое решается намного проще, если не пытаться ничего выдумывать. Не усложняйте жизнь себе и вашим коллегам.
Я лишь привел пример того, что надо будет делать с исключением. Есть огромное количество примеров, когда обрабатывать исключение надо немедленно в том самом месте, где оно выброшено. Для логирование и стэк трейса конечно можно гораздо выше по стеку вызовов, но обернуть ошибку валидации, например, с указанием причины ошибки надо немедленно, пока у нас есть доступ к контексту валидации. Ошибки типа деления на ноль тоже необходимо оборачивать немедленно, пока в самом коде можно понять, что где и почему выбрасывает исключение, а не искать все это в стек трейсе. И таких примеров очень много, и даже сам php предусматривает механизм добавления новой информации на каждом уровне стека вызовов через передачу текущего исключения в конструктор нового через параметр previous, что мы активно в наших проектах используем для того, чтобы в каждом архитектурном слое добавить информации из контекста. Условный пример: пользователю не интересно видеть исключение от доктрины NoResultException. В рамках symfony/laravel это надо обернуть в HttpNotFoundException, который в свою очередь будет пойман фреймворком и обернут в html с 404 ошибкой или в соответствующий json. Пример очень простой, но если не вдаваться в детали, то примерно такой подход мы используем в наших проектах с многослойными архитектурами
"try...catch нужно применять очень редко" - это очень спорное утверждение. Как раз в большинстве случаев исключение надо обрабатывать. В реальном проекте большинство случаев будет обрабатывать фреймворк, но это значит только то, что кто-то за вас сделал эту работу, а на самом то деле под капотом надо красиво логировать исключения, возвращать правильный код статуса, может красивы стэк трейс на экран вывести итп.
Создайте свой криптокошелек и вам черным по белому напишут о том, что будет, если вы потеряете ключ. И насколько мне известно, большинство криптокошельков еще и проверят то, что вы знаете свой ключ перед тем, как давать собой пользоваться.
Ещё зависит от тестового задание. На небольшое вроде того, что у автора еще можно согласиться. Но у меня был опыт, когда собеседование проходило сначала в виде теста, мол делай, а я(интервьюер) потом подойду и гляну. После чего мне было предложено написать полноценный rest api для викторины с oauth2 аутентификацией, полной документацией и чтобы это все в докере работало со сроком в неделю(?!). По неопытности я согласился, но задним умом я понимаю, что вне зависимости от того, джуна собеседуют или сеньора, подобные собеседования - это неуважение ко времени, которое человек для вас выделил. От таких собеседований можно смело отказываться, так как скорее всего подобное неуважение будет и в повседневности
Неа, я дождался компилляции и тем не менее получаю краш с последующим возможным зависанием пк при каждой смене локации. Плюс фпс забавно может с 50-55 просесть до 20, при этом сильно растет потребление оперативки и видеопамяти. Помогает понижение качества текстур, но ненадолго. Подозреваю, что источник утечек памяти не только в упомянутой библиотеке, так как 8 гигов видеопамяти и 32 гига оперативы съедаются очень быстро
Вы совершаете типичную ошибку: исключения != ошибка. В php к сожалению разница между Exception и Error условная. Но в других языках это не так. Именно ошибки ловить не стоит, а в других языках это вообще невозможно, потому что они действительно нужны чтобы просто уронить программу, но речь то про исключения, а исключения != ошибки. Вы же их мешаете в своих утверждениях. Пример исключения: передача 0 в делитель, потому что операция деления принимает 2 числовых операнда, но есть 1 случай, когда деление не сработает. Пример ошибки: передача строки в операцию деления, потому что деление работает только с числами. То, что php позволяет ловить и ошибки, и исключения - это, имхо, большое упущение, поэтому надеяться можно только на линтеры и code review.
Он отличается тем, о чем я вам твержу уже несколько комментариев: это случай, когда у вас нет глобального обработчика исключений
Опять же, разница исключений и ошибок: исключения стоит ловить сразу. Зачем мне на уровне контроллера оборачивать метод, в котором через несколько слоев есть вызов метода из доменного слоя, в котором есть деление и потенциально там может быть деление на 0? Нет, надо ловить исключение сразу. При чем возможно ловить его в самом доменном слое, а затем оборачивать в исключения доменного уровня.
Опять же путаются исключения с ошибками. Я не знаю, что у вас за принципы, но даже если настроить отображение ошибок правильно, то вы просто ошибку замаскируете под статус код 500, чего пользователь в нормальном сервисе видеть никогда не должен.
В том то и дело, что как на ошибки смотрите на исключения вы. Вы же их мешаете в своих утверждениях, хотя это разные вещи, пусть и технически в php они практически не отличаются
Для того, чтобы у вас был централизованный обработчик ошибок, вы должны написать его или воспользоваться готовым решением. Возможно я открою вам тайну, но симфони позволяет выкидывать ненужные компоненты
С него все и началось, поэтому глупо от него отмахиваться. Такое ощущение, что вам просто не хватит аргументов, чтобы поспорить с тем, что данные пример - наглядное доказательство того, о чем я говорю
Какая глупость... Да будет вам известно, что исключение - это такой же легальный возврат из функции, как и return. Бывают случаи, когда вам возвращаемое значение из функции не нужно, но таких случаев единицы. Если исключение кидать, если его не надо обрабатывать или случаев, когда его надо обработать очень мало? Проще уже самому исключительные случаи предусмотреть и не кидать исключение. Наверное его кидают, потому что вариантов обработки, как и случаев, когда это действительно нужно много, и проще отдать это на усмотрение пользователю. С исключениями то же самое, что и возвращаемым значением: в единицах случаев нам надо не ловить исключение, чтобы уронить скрипт. В чуть большем количестве случаев можно обойтись глобальным перехватчиком. В остальных случаях нам почти всегда исключения надо ловить и правильно обрабатывать. Может не прямо в месте вызова функции, а на несколько уровней выше, но ловить надо, иначе у вас будут странности, типа того, что я порой вижу как на некоторых сайтах с упавшей базой прямо в браузер кидается PDOException
Такое решение не должно быть в пользовательском коде, потому что вы решаете простую задачу сложным путем. Помимо этого магия с атрибутами и рефлексией... Вместо слов, стоит процитировать 2 поговорки из Zen of Go: Clear is better then clever, Reflection is never clear. Максимально тупое, в хорошем смысле, решение всегда выигрышнее: оно понятно любому джуну, и вам не нужно будет тратить часы на объяснение того, каким образом работает решение подобно вашему. С более опытными разработчиками вы тоже потратите часы, но на объяснение причины того, почему так
@FanatPHP Во-первых, по поводу исключений с ошибкой валидаций: laravel кидает исключение, ктторое мапится на 429 уод http при ошибке валидации. Это норма.
Во-вторых, по поводу стек трейсов, логирования итп. Лично ВАМ этого делать не надо, потому что используя фреймворк, кто-то за ВАС уже это сделал. Это не значит, что теперь вам об исключениях не надо заботиться. Как только вы изолируетесь от фреймворков, или используете минималистичные фреймворки, это становится ВАШЕЙ проблемой. Это как раз случай автора.
В-третьих, по поводу вашего решения. У меня при прочтении возникало только одно слово в голове: "зачем?!"(в оригинале грубее). Вы напрочь игнорируете принцип KISS, и вы напрочь игнорируете существующие решения. Ваше решение в отличии даже от первого варианта выглядит проигрышнее по 2ум причинам: 1) ваше решение актуально только для симфони, в то время как первое решение с обычным try с несколькими блоками catch работает везде и всегда 2) первое решение максимально простое, если не сказать что тупое, его поймет любой джун. Но если вас смущает, что в блоках catch почти одинаковый код, то для вас есть простое решение: из вашего решения выкидываете все, кроме интерфейса StatusCodeProvider, наследуете его от Throwable, что автоматически обяжет пользовательское исключение наследовать Exception или Error, а затем вместо нескольких catch блоков использовать один, который ловит StatusCodeProvider. Это если придумываете велосипед. В симфони просто реализуйте интерфейс HttpExceptionInterface, остальное за вас сделает фреймворк. К чему эта магия с глобальным перехватчиком ивентов симфони, рефлексией и атрибутами? Это называется Overengineered garbage code: вы решаете очень простую задачу каким-то хитровыдуманным способом. Нафига?! Вы любите острые ощущения в продакшене?
Исключения действительно нужны для чистоты кода, но ваше решение - это прямая противоположность чистоте кода. Чистый код в первую очередь - это понятный каждому код, выполняющий четко свою задачу. Для простой задачи вы придумываете магическое решение, которое решается намного проще, если не пытаться ничего выдумывать. Не усложняйте жизнь себе и вашим коллегам.
Я лишь привел пример того, что надо будет делать с исключением. Есть огромное количество примеров, когда обрабатывать исключение надо немедленно в том самом месте, где оно выброшено. Для логирование и стэк трейса конечно можно гораздо выше по стеку вызовов, но обернуть ошибку валидации, например, с указанием причины ошибки надо немедленно, пока у нас есть доступ к контексту валидации. Ошибки типа деления на ноль тоже необходимо оборачивать немедленно, пока в самом коде можно понять, что где и почему выбрасывает исключение, а не искать все это в стек трейсе. И таких примеров очень много, и даже сам php предусматривает механизм добавления новой информации на каждом уровне стека вызовов через передачу текущего исключения в конструктор нового через параметр previous, что мы активно в наших проектах используем для того, чтобы в каждом архитектурном слое добавить информации из контекста. Условный пример: пользователю не интересно видеть исключение от доктрины NoResultException. В рамках symfony/laravel это надо обернуть в HttpNotFoundException, который в свою очередь будет пойман фреймворком и обернут в html с 404 ошибкой или в соответствующий json. Пример очень простой, но если не вдаваться в детали, то примерно такой подход мы используем в наших проектах с многослойными архитектурами
"try...catch нужно применять очень редко" - это очень спорное утверждение. Как раз в большинстве случаев исключение надо обрабатывать. В реальном проекте большинство случаев будет обрабатывать фреймворк, но это значит только то, что кто-то за вас сделал эту работу, а на самом то деле под капотом надо красиво логировать исключения, возвращать правильный код статуса, может красивы стэк трейс на экран вывести итп.
Создайте свой криптокошелек и вам черным по белому напишут о том, что будет, если вы потеряете ключ. И насколько мне известно, большинство криптокошельков еще и проверят то, что вы знаете свой ключ перед тем, как давать собой пользоваться.
А может дело в том, что у мигрантов из Южной Америки уже есть финансовые проблемы у себя дома?
Ещё зависит от тестового задание. На небольшое вроде того, что у автора еще можно согласиться. Но у меня был опыт, когда собеседование проходило сначала в виде теста, мол делай, а я(интервьюер) потом подойду и гляну. После чего мне было предложено написать полноценный rest api для викторины с oauth2 аутентификацией, полной документацией и чтобы это все в докере работало со сроком в неделю(?!). По неопытности я согласился, но задним умом я понимаю, что вне зависимости от того, джуна собеседуют или сеньора, подобные собеседования - это неуважение ко времени, которое человек для вас выделил. От таких собеседований можно смело отказываться, так как скорее всего подобное неуважение будет и в повседневности