See the exact variable values and call stack at the moment your Rails app crashes, without adding print statements.
Run arbitrary Ruby commands in the context of a crashed request to probe what went wrong.
Click a file reference on the error page to jump directly to that line in your code editor.
Add it to any Rack-based Ruby app such as Sinatra as a middleware layer for better error output.
Must never be used in production, the live console exposes full application state and may reveal private data.
Better Errors is a Ruby library that replaces the default error page shown in Rails applications during development with a significantly more informative one. When your app crashes, instead of seeing a basic stack trace, you get syntax-highlighted source code for each frame in the call stack, the values of local and instance variables at the point of failure, and a live console where you can type Ruby commands directly in the context of the error. The library works with any Ruby web app that uses the Rack interface, which is the standard foundation most Ruby web frameworks sit on, not just Rails. For Rails apps, adding the gem to your development dependencies is all that is needed. For other frameworks, you add it manually as a middleware layer, which is a component that sits in the request-handling pipeline. One useful feature is click-to-open: the error page shows a link next to each file reference that opens that file directly in your code editor at the right line. This requires setting an environment variable to tell the library which editor you use. The library should only ever be used in the development environment on your own machine. The live console exposes the full state of your running application, and the error page may contain private information from your codebase or data. The README explicitly warns against running it in production or on any publicly accessible server. A known limitation is that the live console stores session state in a single server process. If you are running a development server with multiple worker processes, a follow-up request from the error page may land on a different worker that has no memory of the original crash context, resulting in a session expiry message. The fix is to configure development to use only one worker process.
← bettererrors on gitmyhub — every repo by this author, as a profile.
Verify against the repo before relying on details.