> I find it very useful when you develop something for Web and you don't
> have access to apache logs. For myself, I'm using PrettyException when 
> I
> develop a web site, and when it's time to release it, i turn 
> PrettyException off.

This is indeed a critical component of any web-application framework. 
How easy is it to spot an error, how much information are you supplied 
to locate it, and how much time does the fix-test cycle take.

Rails is extremely focused on providing a grade-A handle at all three 
crisis points. At http://www.loudthinking.com/share/template_error.html 
is a look at an old version of how exception handling in templates was 
done in Rails.

In the current version, it's also tracking the nesting of templates (so 
when an error occurs in an included template, you can see how included 
it up the chain). The template parameter dumps are also made much more 
readable by using YAML to do pretty printing.

More importantly, though, is that Rails acts intelligently in the face 
of stackdumps and collection inspections. I always found it so funny to 
read a dump from Tomcat. 120 lines of framework internals exposed to 
the unwitting spectator. Totally oblivious as what to look for.

So as far as it's possible, Rails will determine what's relevant in a 
stacktrace (the lines from your own app) and in a collection dump (the 
variables you assigned) and then deemphasize the rest.

Of course, these details views inside the internals of a Rails 
application are only exposed to requests deemed "local". Everyone else 
will automatically be routed to a public error page.

The cool thing about having this distinction in code is that you can 
keep it in a production system. So when you need to debug something on 
a live system, you'll have a condition present that triggers the local 
condition for the developer (like a fixed IP), so he'll get the full 
story when he needs to investigate real-world bugs.

And in the real world is where he's likely to need the information the 
most. It's where all those odd inputs he never thought about are 
popping up. And without a looking glass, it's all too easy to just rip 
out your hear in frustration over "this shouldn't be happening!". When 
the internals are transparent, the solution is often obvious.

(I cross-posted this to Loud Thinking: 
http://www.loudthinking.com/arc/000274.html)
--
David Heinemeier Hansson,
http://www.rubyonrails.org/  -- Web-application framework for Ruby
http://www.instiki.org/      -- A No-Step-Three Wiki in Ruby
http://www.basecamphq.com/   -- Web-based Project Management
http://www.loudthinking.com/ -- Broadcasting Brain
http://www.nextangle.com/    -- Development & Consulting Services