ООП и куда движемсо - 18, или про ошибки и не только в ООП
вообще исключения, натянутые на систему ООП, вызывают зачастую просто, ну, неимоверные оО? при этом много чего не хватает в этой вот фиговине. например
- нужен lazy тип ошибок. которые можно ключиком снаружи переключить на full. кто мешает вызывать в дев среде исключения при парсинге запроса sql, где в левой части висит строка, а не подставляемый параметр? а на проде - выключать. или не очень.
но тут, и в целом когда разгребаешь системку (тм) обработки ошибок in common, ваще возникает масса вопросов не просто к исключениями или чо там, а к привычной системе и стратегиям обработки. типичнейший пример, ошибки при create file without dir. тут ведь даже не ошибки, а стратегически нужен слегка другой подход, ведь создать файл вместе с кучей папок лучше by default.
второе, при стратегическом подходе нужны чистые енвайронменты. на которых обычно проявляется овер 50% ошибок. ведь разрабы (и админы, чо уш там) привыкли работать в помойке. эт полезно, может, но нифига не продакшеново и не error-free-шево.
даже эти пункты показывают, насколько эта вот тема вообще находится в полной ж относительно разработанности. и точек, куда можно плюнуть - не одна, не две. поэтому и дальше чисто сумборно, может потом когда-нить получится разгрести это все...
нужна локализация эксепшнов. почему к примеру для выброса в конкретном классе мне нужно ваять отдельный глобальный по видимости эксепшн?? а почему бы не назвать его по имени класса+плюха?
почему throw new Exception, а не throw Exception? расскажите.
почему тонны кода составляют пустые exception, которые можно чисто на лету генерить? я вот хочу throw FicPoimiKak, дык зачем мне создавать под это еще и структуру - наследника, который чисто в одном месте по имени ловиться будет и все? натянули шарик, называется, на елку.
и вообще, странно, когда видишь целую папку Exception для модуля где вызовы new Thing from folder раскиданы по коду.
а как, к примеру, вообще пользовать исключения модуля, пусть, к мемкешу? ведь отделить важные от неважных исключений ща - никак, совсем. а по названиям они даже с классами обычно (!!) не совпадают.
- нужен lazy тип ошибок. которые можно ключиком снаружи переключить на full. кто мешает вызывать в дев среде исключения при парсинге запроса sql, где в левой части висит строка, а не подставляемый параметр? а на проде - выключать. или не очень.
но тут, и в целом когда разгребаешь системку (тм) обработки ошибок in common, ваще возникает масса вопросов не просто к исключениями или чо там, а к привычной системе и стратегиям обработки. типичнейший пример, ошибки при create file without dir. тут ведь даже не ошибки, а стратегически нужен слегка другой подход, ведь создать файл вместе с кучей папок лучше by default.
второе, при стратегическом подходе нужны чистые енвайронменты. на которых обычно проявляется овер 50% ошибок. ведь разрабы (и админы, чо уш там) привыкли работать в помойке. эт полезно, может, но нифига не продакшеново и не error-free-шево.
даже эти пункты показывают, насколько эта вот тема вообще находится в полной ж относительно разработанности. и точек, куда можно плюнуть - не одна, не две. поэтому и дальше чисто сумборно, может потом когда-нить получится разгрести это все...
нужна локализация эксепшнов. почему к примеру для выброса в конкретном классе мне нужно ваять отдельный глобальный по видимости эксепшн?? а почему бы не назвать его по имени класса+плюха?
почему throw new Exception, а не throw Exception? расскажите.
почему тонны кода составляют пустые exception, которые можно чисто на лету генерить? я вот хочу throw FicPoimiKak, дык зачем мне создавать под это еще и структуру - наследника, который чисто в одном месте по имени ловиться будет и все? натянули шарик, называется, на елку.
и вообще, странно, когда видишь целую папку Exception для модуля где вызовы new Thing from folder раскиданы по коду.
а как, к примеру, вообще пользовать исключения модуля, пусть, к мемкешу? ведь отделить важные от неважных исключений ща - никак, совсем. а по названиям они даже с классами обычно (!!) не совпадают.