-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Обработка ошибок
- Автор темы Фанат
- Дата начала
Ну а что в php принципиально то отличается? Не так уж и много:
- magic-функции, которые вполне можно применить к месту для "прокси-подобных" классов (заметное, кстати, преимущество)
- затраты на инстанциацию (при нынешнем железе почти не ощущаются)
- помойка встроенных функций (если задуматься, особо таки ничем не хуже помойки джавовских либ, вопрос привычки)
- практически невозможно "персистентить" конфигурацию, в том смысле, что если джаве вполне себе нормально распарсить xml с конфигом, то в php делать это на каждый запрос - жирно (никто не мешает хранить конфиги в .php, с правильно настроенным акселератором и не кривой реализацией sapi (mod_php или fpm) все сляжет в шаред мемори)
- тормозной reflection (никто не мешает использовать ту или иную реализацию reflection cache или обходиться вовсе без, благо есть и другие способы получать runtime информацию)
- специфика автолоада (если придерживаться подхода one class - one file, то сводится к тому же)
- неймспейсы (ждем php 5.3 - да и если не использовать новые бажные фишки типа phar, уже вполне себе стабилен, хотя есть нюансы)
- всякие мелочи, типа местами странного type conversion, к которым мы уже привыкли, ибо сынок это родина %)
не вижу ничего принципиально влияющего на архитектуру =)
- magic-функции, которые вполне можно применить к месту для "прокси-подобных" классов (заметное, кстати, преимущество)
- затраты на инстанциацию (при нынешнем железе почти не ощущаются)
- помойка встроенных функций (если задуматься, особо таки ничем не хуже помойки джавовских либ, вопрос привычки)
- практически невозможно "персистентить" конфигурацию, в том смысле, что если джаве вполне себе нормально распарсить xml с конфигом, то в php делать это на каждый запрос - жирно (никто не мешает хранить конфиги в .php, с правильно настроенным акселератором и не кривой реализацией sapi (mod_php или fpm) все сляжет в шаред мемори)
- тормозной reflection (никто не мешает использовать ту или иную реализацию reflection cache или обходиться вовсе без, благо есть и другие способы получать runtime информацию)
- специфика автолоада (если придерживаться подхода one class - one file, то сводится к тому же)
- неймспейсы (ждем php 5.3 - да и если не использовать новые бажные фишки типа phar, уже вполне себе стабилен, хотя есть нюансы)
- всякие мелочи, типа местами странного type conversion, к которым мы уже привыкли, ибо сынок это родина %)
не вижу ничего принципиально влияющего на архитектуру =)
Alexandre
PHPПенсионер
использую как if ( !$link= mysql_connect() ) die ( mysql_error() )
так и try/catch
все зависит от размера и сложности задачи
но в большом и сложном ООП надо стараться использовать второе, что у меня не всегда хорошо получается. За частую это только одно вложение с одним Exeption. Теоретически должно быть не так, должны быть разработаны свои классы Exeption и их обработка должна быть многоуровневой..
видно мои задачки слишком мелкие для этого...
так и try/catch
все зависит от размера и сложности задачи
но в большом и сложном ООП надо стараться использовать второе, что у меня не всегда хорошо получается. За частую это только одно вложение с одним Exeption. Теоретически должно быть не так, должны быть разработаны свои классы Exeption и их обработка должна быть многоуровневой..
видно мои задачки слишком мелкие для этого...
atv
Новичок
На нижнем уровне у тебя есть ошибка доступа к файлу, и даже в рамках одного приложения это ошибку по разному нужно обрабатывать, в зависимости от логики приложения, т.е. на верхнем уровне.
На один файл можно закрыть глаза и создать заново, вместо другого использовать третий, а в четвёртом завершить работу приложения. Как ты в классе File, который кидает одно и тоже исключение при ошибке доступа, обработаешь все эти ситуации...
Тема уже неоднократно обсуждалась http://phpclub.ru/talk/showthread.php?s=&threadid=113810
try {
} catch (Exception $e) {
}
//finally
if (isset($e)) {
throw($e);
}
некрасиво, но работает
а чем плох сборщик мусора в 5.3? отличный сборщик.
в веб деве не вижу потребности
множество способов добиться той же цели, начиная с простейших REST и заканчивая всякими phporb
fixxxer,
>Какая у всех каша в голове.
"художника обидеть может каждый", предложи что-то не абстрактное?
IMHO смысл и достоинство PHP как-раз в доступности простых решений и свободе выбора.
На Java нет простых решений, зато придумали костыль - runtime exceptions.
Обработку каждого плевка писать влом, поэтому все эксепшены объявляются runtime и "ловятся" системой. За что боролись.
>Какая у всех каша в голове.
"художника обидеть может каждый", предложи что-то не абстрактное?
IMHO смысл и достоинство PHP как-раз в доступности простых решений и свободе выбора.
На Java нет простых решений, зато придумали костыль - runtime exceptions.
Обработку каждого плевка писать влом, поэтому все эксепшены объявляются runtime и "ловятся" системой. За что боролись.
да просто все уже сто раз написано про то для чего нужны исключения.
http://java.sun.com/docs/books/tutorial/essential/exceptions/advantages.html
http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html
http://java.sun.com/docs/books/tutorial/essential/exceptions/advantages.html
http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html
Alexandre
PHPПенсионер
эксепшены быи придуманы, чтоб отлавливатть висящие ссылки. Если у нас в коде где-то попалась "висящая ссылка", мы все подозрительные место обкладываем try/catch - и кидаем соответствующий эксепшен. Иначе код превращается либо в саппогети, либо имеем гемор в отладке.
В РНР все на много проще, хотя тоже иногда вылазиет runtime-ошибка, и порой трудно определить к каком из мегабайта кода она произошла. А в эесепшене - пожалуйста, есть вся информация. А нужно информации больше (например для логов еще добавить REQUEST_URI, time(), pid и прочее ), то можно расширить класс и вперед и с песней.
а кстати вот последние снепшоты 5.3 на моем коде работает стабильнее чем 5.2 хехе. ну то есть работает стабильно (5.2 валится в корку при использовании reflection, причем где-то в zval_destruct, сука. и простой репродакшен кейс не получается. отрубать zend_mm и ковырять valgrind я в гробу видел, пускай лучше 5.3 быстрее релизят хыхы).
вообще лучше бы повыкидывали всякое ненужное говно типа phar (который у меня сегфолится при первом же запуске - при попытке заюзать pear, хехе), и релизили - на мой взгляд, нынешний 5.3 много стабильнее чем был 5.0 на момент релиза - а тогда ранний релиз пошел сильно на пользу (хоть и матюгов было полно хехехе)
вообще лучше бы повыкидывали всякое ненужное говно типа phar (который у меня сегфолится при первом же запуске - при попытке заюзать pear, хехе), и релизили - на мой взгляд, нынешний 5.3 много стабильнее чем был 5.0 на момент релиза - а тогда ранний релиз пошел сильно на пользу (хоть и матюгов было полно хехехе)
