Черт я говорил про удаление), а в случае выборки метод опять же должен вернуть пустой набор, если он возвращает наборы, либо null, если он возвращает row.
А уже в контроллере можно делать так if ($row)

В выборках наличие непустого id контролируется, например, через роутинг -> news_id => '\d+'

Нет). Тем о чем Вы написали занимается валидация, которая конечно может быть частью модели, но никак не частью метода удаляющего данные. А в данном случае метод должен вернуть 0, он ведь не затронул ни одну строку?

Мы с вами переписываемся одновременно в двух темах и трех ветках :D

Да дело ведь не в информативности. Исключения используемые для управления логикой приложения подобны goto.

Логично использовать исключения в исключительных ситуациях.
Если значение не найдено и скрипт должен продолжать работать дальше с учетом этого обстоятельства, то это не исключительная ситуация. Если элемент не найден (например это была статья на которую мы попытались зайти), то это ошибка 404, а значит исключительная ситуация, которую, в случае с зендом, обработает плагин ошибок и перенаправит на ErrorController.

Методы работающие с наборами в случае если ничего не найдено должны возвращать пустой набор, но никак не бросать исключение. Если нормальная логика программы построена через try… catch, то это повод задуматься)

То что описано в статье не является бизнес логикой, и если автору удобно что его шлюзы делают это так, то почему бы и нет? Ведь это и есть задача шлюза — взаимодействовать с таблицой в базе.

В данном случае модель как раз равна таблице, т.к. Zend_Db_Table это реализация паттерна «шлюз таблицы». В остальных случаях предпочтительно использовать модель сохраняемую в базу с помощью маппера, который в свою очередь может использовать шлюзы.

Если посмотреть в тикеты зенда то можно увидеть что в ближайшем будущем планируется переделать where так чтобы он принимал массив.

> Можно, но зачем, если все тоже самое есть в PEAR и нет риска тянуть за собой в виде зависимостей горы ненужного?

Можно из PEAR, но зачем если все тоже самое есть в ZF? ))

Все зависит от конкретной ситуации. Конкретно в моих проектах везде ZF и скорее всего я предпочту использовать компоненты ZF.

ЗФ, раньше, был ценен именно как набор библиотек), да и сейчас почти любой компонент можно использовать отдельно от фреймворка.

Как то так
RewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php

В нашем проекте каждый тест выполняется в отдельной транзакции, и программисты избавлены от необходимости следить за созданными объектами и их удалением.

Что Вы ждете в ответ написав такой комментарий?
Получите то что заслуживаете, и языки здесь ни причем.

В ZF это делается так framework.zend.com/manual/en/zend.view.helpers.html#zend.view.helpers.initial.action

И вот что написано в performance guide framework.zend.com/manual/en/performance.view.html#performance.view.action

Хотя здесь возможно и другой алгоритм.

Где-то пол года назад делал что то подобное для своих саттелитов. Алгоритм использовался достаточно простой и вместе с тем эффективный. В двух словах:
1. Чистим документ от всего лишнего, комментарии, скрипты, атрибуты, вообщем все кроме абзацев, tr (либо td) и дивов.
2. Дальше разбиваем все это дело в массив используя разделитель либо див либо td (или tr). (В этом месте автоматизации добиться не удалось, поэтому для каждой ленты я указывал какая это верстка)
3. Подсчитывалось количество русских букв в каждом элементе. В каком элементе массива букв оказалось больше тот и победил )).
А дальше мы его прогоняем через tidy и вуаля, наш контент готов.

а вы служили?