нормальный результат, если метод возвращает null или false, когда ничего не найдено. Exception — исключение, нарушение нормального хода вещей. То, что вы не продумали (smtp не доступен и сообщение не удается отправить сейчас же), или предусмотрели что здесь что-то может пойти не так (нет прав на создание директории файловым менеджером).
С другой стороны, эти процессы могут быть необязательной частью некоей стратегии, которая перехватит выброшенные вашими сервисами исключения и выполнит необходимые действия (н-р поставит сообщение в очередь отложенной отправки сообщений).
2-е правило при использовании Exception — не перехватывайте Exception, которые не можете обработать.
Например в Zend Framework все исключения перехватываются FrontController-ом и обрабатываются им (записываются в лог). Я в своих контроллерах также перехватываю целевые исключения, когда обращаюсь к сервисам (н-р Zend_Db) и обрабатываю их (н-р вывожу форму регистрации с заполненными полями), не показывая пользователю ненужной инфы об ошибках (выдавая ему сообщение «Сервис временно не доступен, попробуйте повторить регистрацию позже»)
Исключение должно порождаться лишь нарушением нормального выполнения кода. Т.е. в случае ошибки. Вашей ошибки, системной, или ошибки пользователя (т.е. в итоге — вашей), исключающей возможность нормального продолжения работы линейного кода вашего приложения.
Более того, если Вы используете библиотеку н-р в качестве адаптера (Zend_Db) и в вашем сервисном слое она вызывается, Вы, как хороший разработчик, не должны позволять этому исключению просто так провалиться в контроллер, Вы должны перехватить это исключение, обернуть его в свое и пробросить дальше новое, которое будет содержать в себе тело исходного исключения. Потому что когда-нибудь вы захотите использовать вместо Zend_Db, например, чистый PDO или Doctrine, и чтобы Вам не перелопачивать весь код на предмет перехвата исключений Zend_Db_Exception, а ограничиться лишь теми слоями, которые у Вас непосредственно Zend_Db и используют. Именно для этого в PHP 5.3 в конструкторе исключений появился третий параметр типа Exception, который реализует некоторое подобие приемственности.
Что касается использование использования исключений для управления процессом выполнения — эта идея отвратительна по своей сути и противоречит хорошему тону программирования, и, как уже написано выше, является сходным по сути с безусловным оператором GOTO.
Я это к тому, что подобные сервисы прививают не очень хорошую практику. Слепое их использование может привести к печальным последствиям. Поэтому я за то, чтобы в каждом таком посте был дисклаймер: «это не колесо, это запаска».
ах, вы видимо о других проектировщиках :)) Мы применяем два уровня проектирования, внутренний (структура приложения) и внешний (структура интерфейсов) :) Первый очерчивается программистами до разработки и дополняется по ходу, второй разрабатывается обычно в момент сбора информации менеджером проекта/иа-дизайнером и к моменту разработки конкретного блока/модуля уже готов и правки в нем обычно имеют характер дополнений.
Зависит от того, как работают проектировщики и программисты, и насколько они заинтересованы в продукте. Многое зависит от самой команды, от её структуры и принципов работы. Человек, не имеющий стимулов делать что-то хорошо, врядли сделает Вам качественный продукт.
В нашей команде проектировщик знает некоторые особенности бизнес процессов даже лучше, чем программисты. И разработанные им интерфейсы действительно доставляют, хотя порой и спорим по поводу некоторых логических элементов, делая уступки то в сторону соотвтетствия интерфейса заложенной программно логике, то наоборот. Но в целом могу с уверенностью сказать, что хорошее и удобное бизнес-приложение — это результат работы как программистов (которые проектируют и строят внутреннюю архитектуру) так и проектировщиков интерфейсов (которые проектируют взаимодействие клиента с приложением), которые разрабатывают пользовательскую логику.
Я как-то привык достигать недостижимого, причем порой довольно внезапными и не столь апокалиптическими способами. Однако могу сказать одно, пока Вы не поверите, что быдло можно искоренить, пока Вы не попытаетесь разобраться, откуда оно берется, Вы не сможете этого сделать. Трудно отрицать, что быдло есть в каждом их нас, другое дело, как вы это быдло используете, даете ли ему выход, или ищите альтернативные пути (и есть ли вообще эти пути в вашем восприятии?).
Эмм, и, да, Я из этих, идеалистов, поэтому для меня не существует таких слов, как «невозможно». То, что для Вас невозможно, для меня — «труднодостижимо». Например, я не предлагаю искоренять быдло, достаточно просто сделать так, чтобы быдло боялось выказывать свои быдло наклонности :) Если человеку не хватает разума, чтобы не поступать так, пусть он руководствуется страхом или другим, более понятным ему ощущением.
Бороться нужно не с распространением информации а с теми, кто использует её влияние. Пока вы не искорените быдло, пьяные драки будут происходить, и в них будут страдать невинные люди. Данный пример лишь массовая иллюстрация того, что происходит каждый день с вполне нормальными людьми.
Вам построили красивую зависимость, и Вы схавали это как истину. Не принимая во внимание сторонние факторы. Именно так промывают мозги в зомбоящике. Вам говорят, что происходило, но заостряют внимание лишь на тех моментах, которые должны сформировать вашу точку зрения, лишь мельком или вовсе опуская те, которые могли бы заставить вас задуматься над объективностью навязываемой позиции.
Тоже не вижу ничего страшного в самом влиянии интернетов, а то, что среди собравшихся под окном людей оказалась быдло-компания, которая начала месиво и те, кто его продолжили, это влияние воспитание и этих ваших зомбоящиков, отупинов и прочей фигни, которую мы каждый день хаваем. Кто-то больше, кто-то меньше, но хаваем все!
я, например, использую Module_Bootstrap для инициализации acl, навигации, роутов специфичных для модулей, чтобы каждый модуль был законченным и относительно независимым.
Module_LazyLoad_Bootstrap действительно был бы хорошим дополнением к обычному Bootstrap, но никак не смог бы заместить его. У них просто различные функции.
Это работает, когда у сторон есть регламентированные обязанности. Когда вы оцениваете водителя, вы сами принимаете этот риск. Когда водитель оценивает вас, он рискует еще больше.
а если заказчик в момент отправки говорит «вези меня в московскую область, там мне нужно встретиться с друзьями». Ты пыытаешься уточнить, куда в моск. область — он говорит «не знаю», по дороге скажу.
Потом заказчик говорит, вези в Каширу… и в последний момент оказывается, что ему нужно встретиться у памятника, который, как он думал/подсказали/прочитал, находится в Кашире, а оказывается — в Дубне.
И ТЗ от такого заказчика тоже ничего не стоит, т.к. содержит то, что он читал в филькиной грамоте о том, что он хочет.
админка — это такой раздел «меню» друпал. А все разделы меню свободно перемещаются в рамках базовой функциональности drupal. Вы можете отключать их, перемещать и т.д. Изменить же содержание страниц, открываемых при переходе по ссылке в меню, у вас таким образом не получится.
потрудитесь почитать документацию о системе. Использование str_replace для замены надписей — есть бред.
Корректно захардкореные [t()] модулями надписи можно заменить 2-мя способами: 1. theme, 2. использование массиво $conf['locale_custom_strings_en'], где en — код локали.
С другой стороны, эти процессы могут быть необязательной частью некоей стратегии, которая перехватит выброшенные вашими сервисами исключения и выполнит необходимые действия (н-р поставит сообщение в очередь отложенной отправки сообщений).
Например в Zend Framework все исключения перехватываются FrontController-ом и обрабатываются им (записываются в лог). Я в своих контроллерах также перехватываю целевые исключения, когда обращаюсь к сервисам (н-р Zend_Db) и обрабатываю их (н-р вывожу форму регистрации с заполненными полями), не показывая пользователю ненужной инфы об ошибках (выдавая ему сообщение «Сервис временно не доступен, попробуйте повторить регистрацию позже»)
Более того, если Вы используете библиотеку н-р в качестве адаптера (Zend_Db) и в вашем сервисном слое она вызывается, Вы, как хороший разработчик, не должны позволять этому исключению просто так провалиться в контроллер, Вы должны перехватить это исключение, обернуть его в свое и пробросить дальше новое, которое будет содержать в себе тело исходного исключения. Потому что когда-нибудь вы захотите использовать вместо Zend_Db, например, чистый PDO или Doctrine, и чтобы Вам не перелопачивать весь код на предмет перехвата исключений Zend_Db_Exception, а ограничиться лишь теми слоями, которые у Вас непосредственно Zend_Db и используют. Именно для этого в PHP 5.3 в конструкторе исключений появился третий параметр типа Exception, который реализует некоторое подобие приемственности.
Что касается использование использования исключений для управления процессом выполнения — эта идея отвратительна по своей сути и противоречит хорошему тону программирования, и, как уже написано выше, является сходным по сути с безусловным оператором GOTO.
Даже без наличия опыта, это не такая и сложная задача.
В нашей команде проектировщик знает некоторые особенности бизнес процессов даже лучше, чем программисты. И разработанные им интерфейсы действительно доставляют, хотя порой и спорим по поводу некоторых логических элементов, делая уступки то в сторону соотвтетствия интерфейса заложенной программно логике, то наоборот. Но в целом могу с уверенностью сказать, что хорошее и удобное бизнес-приложение — это результат работы как программистов (которые проектируют и строят внутреннюю архитектуру) так и проектировщиков интерфейсов (которые проектируют взаимодействие клиента с приложением), которые разрабатывают пользовательскую логику.
Эмм, и, да, Я из этих, идеалистов, поэтому для меня не существует таких слов, как «невозможно». То, что для Вас невозможно, для меня — «труднодостижимо». Например, я не предлагаю искоренять быдло, достаточно просто сделать так, чтобы быдло боялось выказывать свои быдло наклонности :) Если человеку не хватает разума, чтобы не поступать так, пусть он руководствуется страхом или другим, более понятным ему ощущением.
Вам построили красивую зависимость, и Вы схавали это как истину. Не принимая во внимание сторонние факторы. Именно так промывают мозги в зомбоящике. Вам говорят, что происходило, но заостряют внимание лишь на тех моментах, которые должны сформировать вашу точку зрения, лишь мельком или вовсе опуская те, которые могли бы заставить вас задуматься над объективностью навязываемой позиции.
Module_LazyLoad_Bootstrap действительно был бы хорошим дополнением к обычному Bootstrap, но никак не смог бы заместить его. У них просто различные функции.
… хабр не так плох.
Потом заказчик говорит, вези в Каширу… и в последний момент оказывается, что ему нужно встретиться у памятника, который, как он думал/подсказали/прочитал, находится в Кашире, а оказывается — в Дубне.
И ТЗ от такого заказчика тоже ничего не стоит, т.к. содержит то, что он читал в филькиной грамоте о том, что он хочет.
Корректно захардкореные [t()] модулями надписи можно заменить 2-мя способами: 1. theme, 2. использование массиво $conf['locale_custom_strings_en'], где en — код локали.
«не ешь желтый снег»
Вот создатели софта IPhone это не учли…
на мой взгляд XML-RPC адекватно только вслучае использования удаленных подключений.