Что лучшая стратегия состоит в том, чтобы обработать исключения и ошибки в направляющих?

Тот факт, что вы делаете много ручной проверки на исключения, говорит о том, что вы просто не используете их правильно. На самом деле, ни один из ваших примеров не является исключительным.

Что касается несуществующего поста - вы должны ожидать, что пользователи вашего API (например, пользователь, использующий ваш веб через браузер) будут спрашивать о несуществующих постах.

Ваш второй пример (Post.find(5).comments[0].created_at) также не является исключительным. Некоторые посты просто не имеют комментариев, и вы знаете об этом заранее. Так почему это должно вызывать исключение?

То же самое происходит и с примером ActiveRecord::RecordInvalid. Просто нет причин обрабатывать этот случай с помощью исключения. То, что пользователь вводит в форму некорректные данные, является вполне обычным делом, и в этом нет ничего исключительного.

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

С учетом сказанного, это не означает, что вы не можете DRY код, который инкапсулирует эти ситуации. Существует довольно большой шанс, что вы сможете это сделать, по крайней мере, в некоторой степени, поскольку это довольно распространенные ситуации.

Итак, что насчет исключений? Ну, первое правило действительно таково: используйте их как можно реже.

Если вам действительно необходимо их использовать, то существует два вида исключений в целом (как я это вижу):

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

2. исключения, которые вообще не позволяют пользователю использовать приложение. Это последнее средство, которое следует обрабатывать через внутреннюю ошибку сервера 500 в веб-приложениях.

Я склонен использовать метод rescue_from в ApplicationController только для последнего, поскольку для первого типа есть более подходящие места, а ApplicationController, как самый верхний из классов контроллеров, кажется правильным местом для возврата в таких обстоятельствах (хотя в настоящее время какой-нибудь Rack middleware может быть даже более подходящим местом для размещения такой вещи).

-- EDIT --

Конструктивная часть:

Что касается первого, то я бы посоветовал начать использовать find_by_id вместо find, поскольку он не выбрасывает исключение, а возвращает nil в случае неудачи. Тогда ваш код будет выглядеть примерно так:

unless @p = Post.find_by_id(params[:id])
  flash[:error] = "Can't find Blog Post"
end

что гораздо менее болтливо.

Другая распространенная идиома для DRYing такого рода ситуаций - использовать контроллер before_filters для установки часто используемых переменных (например, @p в данном случае). После этого ваш контроллер может выглядеть следующим образом

controller PostsController
  before_filter :set_post, :only => [:create, :show, :destroy, :update]

  def show
      flash[:error] = "Can't find Blog Post" unless @p
  end 

private

  def set_post
    @p = Post.find_by_id(params[:id]) 
  end

end

Что касается второй ситуации (несуществующий последний комментарий), то одним из очевидных решений этой проблемы является перенос всего этого в хелпер:

# This is just your way of finding out the time of the last comment moved into a 
# helper. I'm not saying it's the best one ;)
def last_comment_datetime(post)
  comments = post.comments
  if comments.empty?
    "No comments, yet."
  else
    "Last comment for this post at: #{comments.last.created_at}"
  end
end

Затем, в ваших представлениях, вы просто вызовете

<%= last_comment_datetime(post) %>

Таким образом, крайний случай (пост без комментариев) будет обрабатываться в своем собственном месте и не будет загромождать представление.

Я знаю, все это не указывает на какой-либо шаблон для обработки ошибок в Rails, но, возможно, с некоторыми рефакторингами, подобными этим, вы обнаружите, что большая часть необходимости в какой-либо стратегии для обработки исключений/ошибок просто исчезнет.