You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Almost every Rails app I know leaves default error pages, which is a shame.
In my experience when it comes to implementing custom error pages they are written in plain html and put in public, and after that completely forgotten, differing more and more from layout design.
For 500 API calls, the public/500.html is rendered by default. What should render is JSON with error message.
The solution is to define explicit controller for handling exceptions. That way you can use site layout template, SLIM, rails helpers etc. In general error pages become more dynamic.
Possible downsides
Error handling deadloop (error is thrown from error controller). I'll try to implement some safeguard for this case though. I think of fallback to public/500.html when there is an exception thrown in errors controller.
Also, to prevent such cases I think ExceptionsController should inherit directly from ActionController::Base, instead of ApplicationController. That should protect it from programming errors committed in ApplicationController.
The text was updated successfully, but these errors were encountered:
http://railscasts.com/episodes/53-handling-exceptions-revised
Reasoning
public/500.html
is rendered by default. What should render is JSON with error message.The solution is to define explicit controller for handling exceptions. That way you can use site layout template, SLIM, rails helpers etc. In general error pages become more dynamic.
Possible downsides
Error handling deadloop (error is thrown from error controller). I'll try to implement some safeguard for this case though. I think of fallback to public/500.html when there is an exception thrown in errors controller.
Also, to prevent such cases I think ExceptionsController should inherit directly from ActionController::Base, instead of ApplicationController. That should protect it from programming errors committed in ApplicationController.
The text was updated successfully, but these errors were encountered: