ООП и куда движемсо - 18, или про ошибки и не только в ООП 3
чо можно попробовать еще сказать про эту вот помойку, чисто практически
- например, убрать message из ex или шоп оно было аля const. и сами ex не объекты! по крайней мере в виде new ex. throw ex, так throw ex.
- но так, как ex->getTrace это прикольно и важно, то у нас тут ваще получаются объекты, но не очень объекты. некая сущность, которая возникает по наименованию и делает слепок текущего энвайронмента.
- интересно, что структурно, к примеру, обычно делают dbex, в который включается и фигня с соединением с базой и плохой запрос. именно от него наследуют dbqueryex, который включает запрос. фиговина возникает в момент отлова, ведь ловятся-то по базовому классу, хотя в случае с ex нужно - НАОБОРОТ! ибо фигня с запросом может быть некритичной, а вот фигню с соединением можно скорее вссего поправить только "снаружи" и перезапуском.
что приводит к тому, что вообще чисто стратегически обработка ошибок должна строиться слегка иначе, чем принято в индустрии. и слегка иначе обрабатываться и слегка иначе должны быть конструкции для отлова, облавы и управления. и слегка иначе строиться стратегия не только обработки, но и построения систем, уменьшающих количество ошибковых ситуаций
как бы это попробовать зафиксировать...
пример 1. создать файл и записать туда "во!". обычно запись в несуществующие дирьки отваливается, но это чисто стратегически архитектурный фейл библиотеки, потому, что by default оно должно максимально отрабатывать, создавая директории, вплоть до возникновения ошибок уровня "фс нагнулась шо никак и совсем".
пример 2. сейчас любая фигня вызывает простыню, неудобную посвященным. практически везде. а ведь должна быть на любой чих простая строчка с описаловом. причем, желательно понятным в плане "а чо ваще и где оно завалилось". вон, поиск в файликах кладр адресов. бывает, что адрес не найден, бывает, что файлика нет. когда файлика нет - генерится "файл не найден". причем, где-то в недрах. чо идет, если оно возникает и не перехватывается _сразу_? оно отправляется на сааамый верх и вызывает простыню.
а ведь логичнее _сгенерить_ на уровне выше ex, чисто по названию метода, к примеру, впендюрить туда "файл не найден" и в 90% случаев это будет четкое определение аля parse_cladr called openfile and failed with "куку". примерно понятно? но механизмов подобных сейчас тупо нету.
пример 3. вообще самая удобная система обработки ошибок та, которой нет. то есть - совсем. то есть - не надо ей забивать бошку никак. если я хочу взять картинку с фс, сконвертить и записать, значит у меня должно быть четко три строчки кода. и прилетевшая фигня, улетающая наружу (в логи там или куда) должно содержать четкое описалово - чо и где не вышло. то есть - readfile не отдает false, он либо вылетает либо отдает картинку. конвертилка либо конвертит либо вылетает с форматом и прочей фигней. запись либо пишет либо... и желательно во всех этих местах кейсы аля "могу справиться внутри метода" отрабатывать, а не говорить что "я типа только файл пишу, а дирьки не создаю, потому, что _любая_отмазка_". как минимум - в употребимых библиотеках, которые не для любителей мусора.
- ту стоит упомянуть, что в try оборачивать все дичайше неудобно, ведь кто мешает сделать вариант "а вот тут мы попробуем ченить поймать"?? и да хоть с начала функции или метода автовставить?
$image = read();
$image2 = process($image)
$save($image2)
catch(есличопошлонетак){забили и пошли дальше}. без try ваще. ибо - нуачо, непонятно шоле?
и ветки ex, которые полезные, делать иначе. аля
class db {throw db\critical\connectionfail; throw db\query\parseerr;
catch(db\query) {забыли и пошли}...
а где-то более снаружи catch(db\critical){записали в лог фигню, вернули в очередь к примеру задачку и exit шоп пусть снаружи перезапускается}
и главное - нигде этих вот extends и class в этом примере - НЕ ПИШЕТСЯ! оно все обязано генериться. причем, с названием класса. причем, возможно шо даже throw critical\connactionfail ибо db\ может и само подставляться.
- помимо этого, такая структуризация поможет не только, скажем замаппить и переименовывать исключения (одной библы в другую, к примеру, по веткам), но еще и ваще структурировать более прилично и обрабатывать более локально все это вот.
- и ваще обрабатывать, потому, что подключаешь чо, что кидается ex, а где и чо оно кинет? а тут можно на critical (по стандарту если сделать) навесить что-то.
пример 4. наверно есть логика шоп отделять мух и котлеты в мисках. аля is_exists - это логика, а false при openfile это обязано лететь, а не возвращаться.
- вариант rethrow ваще убогий, потому, что де-факто теряется environment. по-идее при rethrow он должен оставаться тем же, как на момент первого исключения.
- ваще вариант, к примеру $some=find(); if (some === false) должен и обязан быть на исключениях. но - это дичайше неудобно _сейчас_. то есть - нужен ровно такой же, удобный синтаксис с исключениями! и его - нема.
$some=find(); catch( find\notfound ) . и - да, catch вродь как не умеет быть без скобок. фигня.
и чую, что как только по удобству ex придут к return false, ими начнут пользоваться более эээ... структурненько
- например, убрать message из ex или шоп оно было аля const. и сами ex не объекты! по крайней мере в виде new ex. throw ex, так throw ex.
- но так, как ex->getTrace это прикольно и важно, то у нас тут ваще получаются объекты, но не очень объекты. некая сущность, которая возникает по наименованию и делает слепок текущего энвайронмента.
- интересно, что структурно, к примеру, обычно делают dbex, в который включается и фигня с соединением с базой и плохой запрос. именно от него наследуют dbqueryex, который включает запрос. фиговина возникает в момент отлова, ведь ловятся-то по базовому классу, хотя в случае с ex нужно - НАОБОРОТ! ибо фигня с запросом может быть некритичной, а вот фигню с соединением можно скорее вссего поправить только "снаружи" и перезапуском.
что приводит к тому, что вообще чисто стратегически обработка ошибок должна строиться слегка иначе, чем принято в индустрии. и слегка иначе обрабатываться и слегка иначе должны быть конструкции для отлова, облавы и управления. и слегка иначе строиться стратегия не только обработки, но и построения систем, уменьшающих количество ошибковых ситуаций
как бы это попробовать зафиксировать...
пример 1. создать файл и записать туда "во!". обычно запись в несуществующие дирьки отваливается, но это чисто стратегически архитектурный фейл библиотеки, потому, что by default оно должно максимально отрабатывать, создавая директории, вплоть до возникновения ошибок уровня "фс нагнулась шо никак и совсем".
пример 2. сейчас любая фигня вызывает простыню, неудобную посвященным. практически везде. а ведь должна быть на любой чих простая строчка с описаловом. причем, желательно понятным в плане "а чо ваще и где оно завалилось". вон, поиск в файликах кладр адресов. бывает, что адрес не найден, бывает, что файлика нет. когда файлика нет - генерится "файл не найден". причем, где-то в недрах. чо идет, если оно возникает и не перехватывается _сразу_? оно отправляется на сааамый верх и вызывает простыню.
а ведь логичнее _сгенерить_ на уровне выше ex, чисто по названию метода, к примеру, впендюрить туда "файл не найден" и в 90% случаев это будет четкое определение аля parse_cladr called openfile and failed with "куку". примерно понятно? но механизмов подобных сейчас тупо нету.
пример 3. вообще самая удобная система обработки ошибок та, которой нет. то есть - совсем. то есть - не надо ей забивать бошку никак. если я хочу взять картинку с фс, сконвертить и записать, значит у меня должно быть четко три строчки кода. и прилетевшая фигня, улетающая наружу (в логи там или куда) должно содержать четкое описалово - чо и где не вышло. то есть - readfile не отдает false, он либо вылетает либо отдает картинку. конвертилка либо конвертит либо вылетает с форматом и прочей фигней. запись либо пишет либо... и желательно во всех этих местах кейсы аля "могу справиться внутри метода" отрабатывать, а не говорить что "я типа только файл пишу, а дирьки не создаю, потому, что _любая_отмазка_". как минимум - в употребимых библиотеках, которые не для любителей мусора.
- ту стоит упомянуть, что в try оборачивать все дичайше неудобно, ведь кто мешает сделать вариант "а вот тут мы попробуем ченить поймать"?? и да хоть с начала функции или метода автовставить?
$image = read();
$image2 = process($image)
$save($image2)
catch(есличопошлонетак){забили и пошли дальше}. без try ваще. ибо - нуачо, непонятно шоле?
и ветки ex, которые полезные, делать иначе. аля
class db {throw db\critical\connectionfail; throw db\query\parseerr;
catch(db\query) {забыли и пошли}...
а где-то более снаружи catch(db\critical){записали в лог фигню, вернули в очередь к примеру задачку и exit шоп пусть снаружи перезапускается}
и главное - нигде этих вот extends и class в этом примере - НЕ ПИШЕТСЯ! оно все обязано генериться. причем, с названием класса. причем, возможно шо даже throw critical\connactionfail ибо db\ может и само подставляться.
- помимо этого, такая структуризация поможет не только, скажем замаппить и переименовывать исключения (одной библы в другую, к примеру, по веткам), но еще и ваще структурировать более прилично и обрабатывать более локально все это вот.
- и ваще обрабатывать, потому, что подключаешь чо, что кидается ex, а где и чо оно кинет? а тут можно на critical (по стандарту если сделать) навесить что-то.
пример 4. наверно есть логика шоп отделять мух и котлеты в мисках. аля is_exists - это логика, а false при openfile это обязано лететь, а не возвращаться.
- вариант rethrow ваще убогий, потому, что де-факто теряется environment. по-идее при rethrow он должен оставаться тем же, как на момент первого исключения.
- ваще вариант, к примеру $some=find(); if (some === false) должен и обязан быть на исключениях. но - это дичайше неудобно _сейчас_. то есть - нужен ровно такой же, удобный синтаксис с исключениями! и его - нема.
$some=find(); catch( find\notfound ) . и - да, catch вродь как не умеет быть без скобок. фигня.
и чую, что как только по удобству ex придут к return false, ими начнут пользоваться более эээ... структурненько