diff options
| author | Yuki Nishijima <yk.nishijima@gmail.com> | 2019-01-24 18:48:39 -0500 |
|---|---|---|
| committer | Yuki Nishijima <yk.nishijima@gmail.com> | 2019-01-24 20:30:20 -0500 |
| commit | ef40fb6fd88f2e3c3f989aef65e3ddddfadee814 (patch) | |
| tree | 8978ac75289f2043ca532a8f6c4e5977e8785638 /actiontext/test | |
| parent | 5f7d5995a65d97f2592213889672e9c4799556ec (diff) | |
| download | rails-ef40fb6fd88f2e3c3f989aef65e3ddddfadee814.tar.gz rails-ef40fb6fd88f2e3c3f989aef65e3ddddfadee814.tar.bz2 rails-ef40fb6fd88f2e3c3f989aef65e3ddddfadee814.zip | |
Fixed a bug where the debug view does not show the error page properly
There are two cases where the debug view does not show the error details
properly:
* When the cause is mapped to an HTTP status code the last exception is
unexpectedly uwrapped
* When the last error is thrown from a view template the debug view is
not using the `rescues/template_error.html.erb` to generate the view
Both the cases could be fixed by not unwrapping the exception. The only
case where the exception should be unwrapped is when the last error is
an `ActionView::Template::Error` object. In this case the HTTP status
code is determined based on the cause.
There are actually more wrapper exceptions that are intentionally
thrown. However, there is a consistent pattern of setting the original
message and original backtrace to the wrapper exception implemented, so
the debug view will not lose the information about what went wrong
eariler.
Diffstat (limited to 'actiontext/test')
0 files changed, 0 insertions, 0 deletions