S)
ты по другому
Size: a a a
2020 July 09
S)
не count() я спрашиваю
AB
Ребят как выкачать все внутренние файлы с сайта на джумле 2,5 при этом не имея доступа по фтп и без каких то сторонних разрешений?
А
Ребят как выкачать все внутренние файлы с сайта на джумле 2,5 при этом не имея доступа по фтп и без каких то сторонних разрешений?
Хакни
А
// массив для связи соединения пользователя и необходимого нам параметра
$users = [];
// создаём ws-сервер, к которому будут подключаться все наши пользователи
$ws_worker = new Worker("websocket://0.0.0.0:8000");
// создаём обработчик, который будет выполняться при запуске ws-сервера🤔
С
Не подскажете где почитать/посмотреть как "правильнее" использовать кастомные исключения? Как бросать и ловить я знаю, но наткнулся что есть разные стратегии как с ними стоит поступать...
L
Не подскажете где почитать/посмотреть как "правильнее" использовать кастомные исключения? Как бросать и ловить я знаю, но наткнулся что есть разные стратегии как с ними стоит поступать...
Смотрел чувака, у которого в проектах было штук 80 своих кастомных исключений.
Основная фишка в том, что ты ловишь исключение, смотришь его и решаешь, что с ним делать:
1) исключение "программа повела себя неправильно, дальнейшее выполнение невозможно" -> лог и проброс || выход из программы с каким-то человекопонятным выводом в UI. Вероятно, надо как-то уведомить разрабов.
Пример: ты не смог подключиться к БД.
2) Исключение было ожидаемо, ничего критичного, дальнейшее выполнение возможно. Либо тут решаешь, нужно ли логировать, либо выше. И пробрасываешь дальше. Где нужно - обрабатываешь и идешь дальше.
Например, юзер пытается сделать то, на что у него нет прав.
3) это вообще внутреннее исключение вместо return. Тогда не нужно даже логировать. Просто ловишь кетчером того метода, где вызывал и работаешь, как если бы словил return false.
Например, меня учили, что метот validate должен быть void и не принимать никаких параметров, а работать исключительно со свойствами своего класса. И если все валидно - просто ничего не происходит, а если не валидно и нельзя исправить - бросать исключение.
Основная фишка в том, что ты ловишь исключение, смотришь его и решаешь, что с ним делать:
1) исключение "программа повела себя неправильно, дальнейшее выполнение невозможно" -> лог и проброс || выход из программы с каким-то человекопонятным выводом в UI. Вероятно, надо как-то уведомить разрабов.
Пример: ты не смог подключиться к БД.
2) Исключение было ожидаемо, ничего критичного, дальнейшее выполнение возможно. Либо тут решаешь, нужно ли логировать, либо выше. И пробрасываешь дальше. Где нужно - обрабатываешь и идешь дальше.
Например, юзер пытается сделать то, на что у него нет прав.
3) это вообще внутреннее исключение вместо return. Тогда не нужно даже логировать. Просто ловишь кетчером того метода, где вызывал и работаешь, как если бы словил return false.
Например, меня учили, что метот validate должен быть void и не принимать никаких параметров, а работать исключительно со свойствами своего класса. И если все валидно - просто ничего не происходит, а если не валидно и нельзя исправить - бросать исключение.
С
Смотрел чувака, у которого в проектах было штук 80 своих кастомных исключений.
Основная фишка в том, что ты ловишь исключение, смотришь его и решаешь, что с ним делать:
1) исключение "программа повела себя неправильно, дальнейшее выполнение невозможно" -> лог и проброс || выход из программы с каким-то человекопонятным выводом в UI. Вероятно, надо как-то уведомить разрабов.
Пример: ты не смог подключиться к БД.
2) Исключение было ожидаемо, ничего критичного, дальнейшее выполнение возможно. Либо тут решаешь, нужно ли логировать, либо выше. И пробрасываешь дальше. Где нужно - обрабатываешь и идешь дальше.
Например, юзер пытается сделать то, на что у него нет прав.
3) это вообще внутреннее исключение вместо return. Тогда не нужно даже логировать. Просто ловишь кетчером того метода, где вызывал и работаешь, как если бы словил return false.
Например, меня учили, что метот validate должен быть void и не принимать никаких параметров, а работать исключительно со свойствами своего класса. И если все валидно - просто ничего не происходит, а если не валидно и нельзя исправить - бросать исключение.
Основная фишка в том, что ты ловишь исключение, смотришь его и решаешь, что с ним делать:
1) исключение "программа повела себя неправильно, дальнейшее выполнение невозможно" -> лог и проброс || выход из программы с каким-то человекопонятным выводом в UI. Вероятно, надо как-то уведомить разрабов.
Пример: ты не смог подключиться к БД.
2) Исключение было ожидаемо, ничего критичного, дальнейшее выполнение возможно. Либо тут решаешь, нужно ли логировать, либо выше. И пробрасываешь дальше. Где нужно - обрабатываешь и идешь дальше.
Например, юзер пытается сделать то, на что у него нет прав.
3) это вообще внутреннее исключение вместо return. Тогда не нужно даже логировать. Просто ловишь кетчером того метода, где вызывал и работаешь, как если бы словил return false.
Например, меня учили, что метот validate должен быть void и не принимать никаких параметров, а работать исключительно со свойствами своего класса. И если все валидно - просто ничего не происходит, а если не валидно и нельзя исправить - бросать исключение.
Спасибо, очень любопытно
S
Не подскажете где почитать/посмотреть как "правильнее" использовать кастомные исключения? Как бросать и ловить я знаю, но наткнулся что есть разные стратегии как с ними стоит поступать...
L
А вообще, по пхп я чот не нахожу ничего дельного, зато по шарпу и джаве навалом результатов по запросу
custom exceptions best practices. Можно там набраться полезного. Конечно, там очень много про рантайм и checked/unchecked exceptions, но это тоже полезно...AB
А вообще, по пхп я чот не нахожу ничего дельного, зато по шарпу и джаве навалом результатов по запросу
custom exceptions best practices. Можно там набраться полезного. Конечно, там очень много про рантайм и checked/unchecked exceptions, но это тоже полезно...это всегда так кажется что на другом ЯП более дельное что то))
L
Да и в принципе (меня, наверное, запинают здесь за такие слова) я предпочитаю учиться на джавовских практиках, потому что она в энтерпрайзе уде лесятилетиями, и там люди набили очень хорошие шишки и выработали очень хорошие подъоды с точки зрения длятельеой поддержки огромных проектов...
С
это всегда так кажется что на другом ЯП более дельное что то))
Ну я лично конкретно по исключениям только для c++ c# и java в основном вижу в выдаче :(
С
Да и в принципе (меня, наверное, запинают здесь за такие слова) я предпочитаю учиться на джавовских практиках, потому что она в энтерпрайзе уде лесятилетиями, и там люди набили очень хорошие шишки и выработали очень хорошие подъоды с точки зрения длятельеой поддержки огромных проектов...
Спасибо большое, учту эту твою практику :)
L
это всегда так кажется что на другом ЯП более дельное что то))
Не, серьезно...
1 результат - статейка про то, что такое ошибки и исключения
2 результат - стаковерфлоу
3 и далее - что такое исключения и наследования исключений
php custom exceptions best practices:1 результат - статейка про то, что такое ошибки и исключения
2 результат - стаковерфлоу
3 и далее - что такое исключения и наследования исключений
С
А вообще, по пхп я чот не нахожу ничего дельного, зато по шарпу и джаве навалом результатов по запросу
custom exceptions best practices. Можно там набраться полезного. Конечно, там очень много про рантайм и checked/unchecked exceptions, но это тоже полезно..." рантайм и checked/unchecked exceptions" - это к php не применимо?
L
Кстати, из джавачата на вопрос по практикам эксепшнов:
L
кожен др..че як хоче
С
:))
L
" рантайм и checked/unchecked exceptions" - это к php не применимо?
Нинаю. У меня пока всего два - DAOException и DomainException...