It's pretty common for us to use errors to drive a feature. Unfortunately the catchall "Internal Server Error" gobbles up a lot of context of what went wrong, and that makes it hard to figure out what to do next in TDD. I'd like to come up with a way to expose that context in non-prod environments so that we can debug problems.
To be sure, the backtrace is printed to the console if the error occurs while the server is running locally, but if you're driving a feature with something like Capybara it's not easily visible (or least idk where to find this backtrace?). When I think about how this works with a run-of-the-mill acceptance test of some server-rendered Rails page, we often lean on the fact that Rails renders a "special" error page in non-prod environments which includes information about the error that occurred.. This got me to the conclusion that perhaps we should extend the internal server error (and maybe others?) to include the exception in the response in non-prod environments.
What do you think?
It's pretty common for us to use errors to drive a feature. Unfortunately the catchall "Internal Server Error" gobbles up a lot of context of what went wrong, and that makes it hard to figure out what to do next in TDD. I'd like to come up with a way to expose that context in non-prod environments so that we can debug problems.
To be sure, the backtrace is printed to the console if the error occurs while the server is running locally, but if you're driving a feature with something like Capybara it's not easily visible (or least idk where to find this backtrace?). When I think about how this works with a run-of-the-mill acceptance test of some server-rendered Rails page, we often lean on the fact that Rails renders a "special" error page in non-prod environments which includes information about the error that occurred.. This got me to the conclusion that perhaps we should extend the internal server error (and maybe others?) to include the exception in the response in non-prod environments.
What do you think?