-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Цепочки объектов.
- Автор темы akxxiv
- Дата начала
dark-demon
d(^-^)b
и что в нём кривого? то, что он простой, понятный и делает ровно столько сколько нужно? что его легко исправлять без необходимости копания в сложных объектных зависимостях с помощью всяких object inspector-ов? что его легко отлаживать без необходимости вешать тучу исключений, которые потом ещё и отлавливать нужно в обязательном порядке?
dark-demon
d(^-^)b
опять же, если не сложно приведи пример, где их использование оправдано.
тут ещё хочется уточнить насчёт "исключительных ситуаций" - в пхп исключительные ситуации, сиречь фатальные ошибки, приводят к скорому падению скрипта, не контролируемо и с грохотом. механизм же исключений - это прерывание работы одной функции с передачей управления другой. этакий оператор goto, но с заданием адресата не сразу на месте его вызова, а предварительно, до вызова самой функции.
тут ещё хочется уточнить насчёт "исключительных ситуаций" - в пхп исключительные ситуации, сиречь фатальные ошибки, приводят к скорому падению скрипта, не контролируемо и с грохотом. механизм же исключений - это прерывание работы одной функции с передачей управления другой. этакий оператор goto, но с заданием адресата не сразу на месте его вызова, а предварительно, до вызова самой функции.
kruglov
Новичок
Не goto, а return, т.к. функция сломалась, дальше выполняться не может. Но сам скрипт еще может принять решение о дальнейшем продолжении своей работы. Причем это решение принимает не "проштрафившаяся" функция (как Вы предлагаете), а вызвавший ее код.
Функция вроде my_read_file может возвращать контент файла, если все получилось, а может - false, если нет. Или вместо false она может "кидать" кучу разных исключений на выбор - нет_прав_exception, файл_занят_exception, файл_не_найден_exception и т.д. А какого цвета выводить мессагу юзеру и выводить ли вообще - не ее дело.
dark-demon
d(^-^)b
вот именно что сломалась функция и она (функция!) дальше работать не может. какого лешего она пытается вырубить весь скрипт? требуя от программиста каждый раз при её вызове ловить от неё исключения.
если требуется выводить подробную информацию типа "файл не был прочитан потому, что...", то почему бу явно не вызвать функцию выполняющую необходимые проверки? если это можно выяснить только в процессе работы функции - почему бы не написать (переписать) её так, чтобы она возвращала всю необходимую информацию? прямо или опосредованно.
если нас не волнует причина отказа, а важен сам факт этого - зачем оборачивать её вызов в try-catch, если достаточно простой проверки возвращаемого ею значения?
если требуется выводить подробную информацию типа "файл не был прочитан потому, что...", то почему бу явно не вызвать функцию выполняющую необходимые проверки? если это можно выяснить только в процессе работы функции - почему бы не написать (переписать) её так, чтобы она возвращала всю необходимую информацию? прямо или опосредованно.
если нас не волнует причина отказа, а важен сам факт этого - зачем оборачивать её вызов в try-catch, если достаточно простой проверки возвращаемого ею значения?
Wicked
Новичок
dark-demon
в некоторых случаях ты просто не сможешь нормально сделать без эксепшенов. Например, при вызове $a = new ActiveRecord($id), в случае, когда $id окажется невалидным и объект вообще не должен быть создан.
в некоторых случаях ты просто не сможешь нормально сделать без эксепшенов. Например, при вызове $a = new ActiveRecord($id), в случае, когда $id окажется невалидным и объект вообще не должен быть создан.
затем, что проверку ты можешь и заб[ыи]ть сделать, а с кидаемым эксепшеном - нет. Если ты приверженец того, что в программе вообще не должно генериться никаких, даже внутренних ошибок, могу только посочувствовать.
Естественно!
Только не "как ни в чем ни бывало" - а записать детали ошибки в лог, возможно, вывести уведомление пользователю, или, возможно, попробовать еще раз.
Т.о. ошибка вызывает не прекращение работы, не сбой, а только изменение логики работы - т.е. становится не "ошибкой", а внешними данными.
dark-demon
d(^-^)b
почему? вполне можно создать объект, который не будет содержать данных, но свойство "error" будет содержать сообщение об ошибке. ещё можно вспомнить, что php - мягко типизированный язык, поэтому вместо объекта можно вернуть строку с ошибкой.
ну как же
trigger_error ещё никто не отменял.
Wicked
Новичок
о да
это то, о чем мечтает каждый программист.В том то и дело, что нельзя.
trigger_error - это не-recoverable ошибки. Да, есть случаи, когда она нужна, но эта функция подходит далеко не для всех случаев. Так что спасибо, мы как-нибудь так...
-~{}~ 23.05.07 16:07:
Прочитал еще раз твой последний пост, и понял, что пытаюсь вправить моск профессиональному спорщику.
Еще можно гвоздь логарифмической линейкой забивать. Твоя линейка, твой гвозь, твоя селедка на гвозде - кто ж против?
А можно использовать встроенные средства - вместо объекта с полем error получить объект, специально задуманный для этого авторами языка. Это позволяет получить всю нужную информацию для отладки в удобном (для меня) виде, и обработать его в удобном (для меня) месте.
В огороде бузина, а в городе - дядька. Мы говорим об обработке ошибок через бросание/отлов исключений, в частности при создании объектов. При чем тут типы, при чем тут строка? О 4ке речь не идет впринципе.
Если ты кодишь для 4го - то ты вообще не по теме пишешь
А никто и не говорит, что надо о нем забыть. Наличие выбора мне нравится больше, чем отказ от него.
С.
Продвинутый новичок
Мы еще в рамках веб-приложений разговариваем? Я ничего не пропустил? То что "попробовать еще раз" будет происходить в совершенной другой инкарнации скрипта вас не смущает?
И все же хотелось пример хоть одного (1) скрипта, где неудачное создание объекта не ведет к завершению программы, а идет работа по иной ветке алгоритма. Не абстрактный пример, а цитату из конкретного работающего проекта. Именно это я понимаю под термином "бывает".
-~{}~ 23.05.07 20:39:
А еще можно экскаватором клумбы вскапывать. Твоя клумба, твой экскаватор, он же ЛШ-5МУ (лопата штыковая модель 5 моторизированная укрупненная) - кто ж против?
dark-demon
d(^-^)b
это так называемый null-object pattern
кто-то мешает?
какие вызовешь - такие и будут.
чьорт, меня раскусили \(^_^)/
Wicked
Новичок
меня страшными словами не запугаешь
он уместен тогда, когда нас может устроить некоторый пустой объект с особым поведением. Специально сделанный для того, чтобы дальше по коду нас не интересовало, нормальный у нас объект, или null-.
Использовать же null-объект только для сигнализирования об ошибке, в которой заинтересован внешний для класса код - уже не совсем правильно.
PS: /me представил себе null-объект соединения с базой данных
dark-demon
d(^-^)b
Wicked, не только 
такой вариант подходит, когда нам не важно были ли там ошибки. утрированный пример: логирование ошибок; файл заблокирован и не доступен для записи. попытка открыть его обернулась неудачей. надо ли в этом случае пытаться вырубить весь скрипт? или же вполне устроит отправка логов в dev/nul?
StUV, на цпп альтернатив особо и нет с жабой - не знаком.
PS: /me представил себе описанную выше функцию хранящую ошибки в базе данных... открыл локалхост и убедился в её работоспособности
такой вариант подходит, когда нам не важно были ли там ошибки. утрированный пример: логирование ошибок; файл заблокирован и не доступен для записи. попытка открыть его обернулась неудачей. надо ли в этом случае пытаться вырубить весь скрипт? или же вполне устроит отправка логов в dev/nul?StUV, на цпп альтернатив особо и нет
с жабой - не знаком.PS: /me представил себе описанную выше функцию хранящую ошибки в базе данных... открыл локалхост и убедился в её работоспособности