To get it to work with my mixed Padrino/Sinatra rack app I had to do this in each app:
if PADRINO_ENV == "development"
set :raise_errors, true
set :show_exceptions, false
use BetterErrors::Middleware if PADRINO_ENV == "development"
I'm not deeply familiar with Padrino or Sinatra and so it took a lot of experimentation (and source reading) to find the right incantation. But it's working great now!
While normally I'm a massive advocate of "Just not being retarded", I suspect a lot of people are going to drop shells as a result of this gem :(
But is not the rails way to be in the shell, rails console and editor at all times? Instead of trying things out in the browser you have automated testing doing that for you?
I just found an unintended use for this:
I use pry with a `binding.pry` statement to debug my code, Now I can just `raise 'Something'` to do this instead. One upside of this is that I can easily navigate through all the frames from the UI and inspect stuff. If I want to know what env vars are available in some middleware, I can just click on it in the UI and start inspecting it.
One of the things Rails 4 already features is better error pages, though no REPL.
Bugsnag (http://bugsnag.com) is awesome when debugging production errors.
then start the server again:
As with nearly all Rack application servers I know of, you can simply restart the application by creating/updating 'tmp/restart.txt' from your Rails root. Unix's `touch` command does this nicely. With Pow specifically, you can also create '~/.pow/restart.txt' (or '~/Library/Application Support/Pow/Hosts/restart.txt', since it's the same location) and that will force Pow to reload itself.
Also, I've tried that and I'm still getting the same old "Action Controller: Exception..." error. Specifically I have a MySQL error, yet no 'better_errors' showing.
I've already executed 'bundle install' too.
PS: Probably rack-errors would be much better name for this gem.
Edit: Being downvoted. Some people just don't like knowing the truth.
The downvotes may be partly because you are using an article about a specific Ruby project as a jumping off point to promote another language, which is slightly obnoxious - make a thread for your new PHP stuff you are interested in, people who are happily using Ruby don't need to be exhorted to use other languages for no specific reason
> You even have a complete analysis for each request, that you can open with one click:
Do I get the queries generated for the request and time it took for them? And the time it took for the templates to be rendered?
Werkzeug debugger and flask-debug-toolbar are my baseline for debugging toolbars. They don't try to be everything and give me everything I need.
> You guys would be amazed if you tried frameworks like Symfony (instead of discarding PHP for not being beautiful or whatever)
Helpful exception logs and inline repls are one of n things to take into consideration. This alone isn't going to buy any converts.
At the end of day, they are convenience tools. It's not like I can't debug code or profile db requests without them. If I can get an inline context aware repl, superb. If not, good old breakpoints are mighty fine.
In saying that, the PHP LANGUAGE has some pretty glaring and terrifying warts, a fact that Rasmus doesn't try to hide.
I came to Rails from Symfony and there are definitely things I miss. Rails is way better overall, but there are loads of little things that were fantastically useful.