| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
fatal multiple times. Expose tags_text from TaggedLogging to be used for log formatting
Fixes #26134
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an exception is raised, those Action View rendering logs are just
noise for the end developer. I recently silenced those from Web Console,
as we do use Action View rendering in it as well. It used created a half
a screen of rendering logs. I think we can save those in this recent
push for cleaner development logs.
Now, the silencing is a bit hacky and we have a bunch of it now, so we
can also invest in turning off the logs directly from Action View
objects instead of silencing off the logging stream.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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 -
https://github.com/rails/rails/commit/05d89410bf97d0778e78558db3c9fed275f8a614.
[Prathamesh Sonpatki, Jorge Bejar]
|
|
|
|
| |
This change was added in #23203 and it was not conforming our code style.
|
|
|
|
|
|
|
| |
- Changed formatted_code_for to return array of logs to be tagged for each line
- Changed some render tests to match new behaviour of return
Fixes #22979
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Creates fewer request objects and helps to abstract away from internals
|
|
|
|
|
| |
hide the env key in the request object so that other code doesn't need
to know.
|
|
|
|
|
|
| |
ExceptionWrapper only cares about the backtrace cleaner, so lets just
pass the cleaner to the wrapper. It does not need to know that env
exists or what key the backtrace cleaner is stored in
|
|
|
|
| |
We should remove this dependency later.
|
|
|
| |
Avoid logic in ERB and use helpers
|
|\
| |
| | |
Rename #source_extract to #source_extracts in ExceptionWrapper
|
| |
| |
| |
| |
| | |
It returns multiple source extracts since 1ed264bc. Also cleaned its
result structure, as we no longer need the file in a code extract.
|
|/
|
|
|
|
|
|
|
|
| |
Since dbcbbcf2bc58e8971672b143d1c52c0244e33f26 the full trace is shown
by default on routing errors. While this is a nice feature to have, it
does take the attention off the routes table in this view and I think
this is what most of the people look for in this page.
Added an exception to the default trace switching rule to remove that
noise.
|
|
|
|
|
| |
ActionDispatch::ExceptionWrapper seems to be the more natural place for
this method to live in.
|
|
|
|
| |
trace list, closes #17312
|
|
|
|
|
|
| |
Provide the ability to extract the source code of the entire exception stack
trace, not just the frame raising the error. This improves debugging
capability of the error page, especially for framework-related errors.
|
| |
|
| |
|
| |
|
|\
| |
| | |
masgn and response variable
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
| |
Rubinius returns a boolean after such assingment
response = (_, headers, body = @app.call(env))
see https://github.com/rubinius/rubinius/issues/2117
get rid of a local variable
|
|
|
|
|
|
|
| |
It feels more consistent to have this class called "HtmlTableFormatter",
and to have it here with the routes inspector and console formatter,
since it's used for both routing error exceptions and the rails info
page.
|
| |
|
| |
|
|
|
|
|
|
| |
is false.
If it is nil we can't raise the exception
|
| |
|
|
|
|
|
|
|
|
|
| |
When someone gets a routing exception, the routes are rendered (starting in Rails 4.0). This PR brings parity between the html routes in the `rails/info/routes` path and when rendered from an exception. This is the continuation of #8521 which brought html formatted routes.
In addition to bringing parity to the two views, we're keeping our views DRY by rendering off of the same partials. In this case Railties depends on partials provided by ActionDispatch. I'm open to alternative implementations. Ideally both views will use the same code so any improvements or updates to it will be reproduced on both.
<hr />
![](http://f.cl.ly/items/3O1D0K1v0j0i343O3T3T/Screen%20Shot%202012-12-17%20at%203.07.20%20PM.png)
|
| |
|
|
|
|
| |
Follow the consistency defined in dbc43bc.
|
|
|
|
| |
this is so we can show route output in the development when we get a routing error. Railties can use features of ActionDispatch, but ActionDispatch should not depend on Railties.
|
|
|
|
| |
If someone receives a routing error, they likely need to view the routes. Rather than making them visit '/rails/info/routes' or run `rake routes` we can give them that information on the page.
|
| |
|
| |
|
| |
|
| |
|
| |
|