4 ms·

I've yet to see my concerns properly discussed (how to handle exceptions): http://news.ycombinator.com/item?id=1671437 http://news.ycombinator.com/item?id=16714

• tomeric 16y ago
  I believe that's one of the main reasons this won't be on by default. It's going to be a tradeoff, either you accept that an exception can occur after sending a '200 OK' status code and possibly resort to javascript to display the error in a nice way, or you'll use the old fashioned way and send the correct response when the full page has loaded. I'm going to use HTTP Streaming and rely on my tests and Hoptoad to fix errors as soon as they'll occur. I think the performance boost outweighs the consequence of not sending the correct status code when an exception occurs.
• tenderlove 16y ago
  We won't do anything to handle exceptions in 3.1. For 3.1, this is definitely a "use at your own risk" feature. Besides handling exceptions, there are a bunch of caveats for using this. You need to use the right web server (unicorn or specially configured passenger), along with the right proxy (nginx or apache with special configuration) and Ruby 1.9. I've got ideas for handling exceptions, but I just can't make it happen for 3.1. :-(
• rudd 16y ago
  This is the first thing that came to mind for me. I recently wrote a WSGI Python app that made use of chunked encoding, so that it could emit multi-hundred MB text files without loading them all into memory first, and one of the big hurdles was running into an error after having sent some data. In the end I had to implement a fancy Javascript check and keep some state in the app to check if there had been an error and the downloaded file was no good.