In this case statement, there are two patterns that start with the same
line:
when %r{/not_found}
...
when %r{/not_found_original_exception}
...
Because the string "/not_found_original_exception" does match the first
one, it is never routed to what it is supposed to be routed, causing one
of the tests for DebugExceptions to happen to be passing.
After changing the regex expressions back to strings, I noticed that the
test setup is not complete (the template object needs to be a proper
template object). Once I fixed it all the tests started padding.
Plugins interacting with the exceptions caught and displayed by
ActionDispatch::DebugExceptions currently have to monkey patch it to get
the much needed exception for their calculation.
With DebugExceptions.register_interceptor, plugin authors can hook into
DebugExceptions and process the exception, before being rendered. They
can store it into the request and process it on the way back of the
middleware chain execution or act on it straight in the interceptor.
The interceptors can be play blocks, procs, lambdas or any object that
responds to `#call`.
I have been seeing people setting `Logger` instances for `config.logger`
and it blowing up on `rails/web-console` usage.
Now, I doubt many folks are manually setting `ActionView::Base.logger`,
but given that `DebugExceptions` is running in a pretty fragile
environment already, having it crash (and being silent) in those cases
can be pretty tricky to trace down.
I'm proposing we verify whether the `ActionView::Base.logger` supports
silencing before we try to do it, to save us the headache of tracing it
down.
- Earlier we were responding with JSON format for HTML requests in a API
app.
- Now we will respond with HTML format for such requests in API apps.
- Also earlier we were not testing the API app's JSON requests
properly. We were actually sending HTML requests. Now we send correct
JSON requests. Also added more test coverage.
- Based on the discussion from this commit -
05d89410bf.
[Prathamesh Sonpatki, Jorge Bejar]
When a request is made with AJAX and an error occurs, Rails will render
a text-template for the exception instead of the HTML error page
(#11960).
The `.text.erb` variant of the `_source` template is currently missing,
causing HTML to be rendered in the response. This commit adds the text
template.
To keep the page scannable we only only show the first three source
extracts.
Related to #14745.
Before:
```
~/testing-exceptions ᐅ curl 'http://localhost:3000/' -H
'X-Requested-With: XMLHttpRequest'
RuntimeError in PostsController#index
<div class="source " id="frame-source-0">
<div class="info">
Extracted source (around line <strong>#3</strong>):
</div>
<div class="data">
<table cellpadding="0" cellspacing="0" class="lines">
<tr>
```
After:
```
~/testing-exceptions ᐅ curl 'http://localhost:3000/' -H
'X-Requested-With: XMLHttpRequest'
RuntimeError in PostsController#index
Extracted source (around line #3):
*3 raise
```
Non-kwargs requests are deprecated now.
Guides are updated as well.
`post url, nil, nil, { a: 'b' }` doesn't make sense.
`post url, params: { y: x }, session: { a: 'b' }` would be an explicit way to do the same
This will help you debug missing template errors, especially if they
come from a programmatic template selection. Thanks to @dhh for
suggesting that.
As a bonus, also show request and response info on the routing error
page for consistency.
When the value for the required key is empty an ActionController::ParameterMissing is raised which gets caught by ActionController::Base and turned into a 400 Bad Request reply with a message in the body saying the key is missing, which is misleading.
With these changes, ActionController::EmptyParameter will be raised which ActionController::Base will catch and turn into a 400 Bad Request reply with a message in the body saying the key value is empty.
Many named routes have keys that are required to successfully resolve. If a key is left off like this:
<%= link_to 'user', user_path %>
This will produce an error like this:
No route matches {:action=>"show", :controller=>"users"}
Since we know that the :id is missing, we can add extra debugging information to the error message.
No route matches {:action=>"show", :controller=>"users"} missing required keys: [:id]
This will help new and seasoned developers look closer at their parameters. I've also subclassed the routing error to be clear that this error is a result of attempting to generate a url and not because the user is trying to visit a bad url.
While this may sound trivial this error message is misleading and confuses most developers. The important part isn't what's in the options its's what's missing. Adding this information to the error message will make debugging much more obvious.
This is the sister pull request of https://github.com/rails/journey/pull/44 which will be required to get they missing keys into the correct error message.
Example Development Error in Rails: http://cl.ly/image/3S0T0n1T3421
Currently Rack raises a TypeError when it encounters a malformed or
ambiguous hash like `foo[]=bar&foo[4]=bar`. Rather than pass this
through to the application this commit captures the exception and
re-raises it using a new ActionController::BadRequest exception.
The new ActionController::BadRequest exception returns a 400 error
instead of the 500 error that would've been returned by the original
TypeError. This allows exception notification libraries to ignore
these errors if so desired.
Closes#3051
