-
Notifications
You must be signed in to change notification settings - Fork 34
rails.request.exceptions also reports intended exceptions #87
Comments
Hmm. Yes, this is a tricky issue because what we are reporting is the number of exceptions that are bubble out of a controller actions to the layer above. The global exception handlers for things like Did you write your own handler for the |
We rely on the default Rails implementation. As a work around we're using |
Does |
More accurate? - maybe. But! The RecordNotFound exceptions are not included, that is what I know On Thu, Jul 31, 2014 at 12:16 AM, Matt Sanders [email protected]
|
What do you mean with accurate? It's more like what I would expect. Even if On Thursday, July 31, 2014, Matt Sanders [email protected] wrote:
|
Right, so |
True, but then I'd propose for this gem to get rid of |
Just following up on this after lots of thought. I'd like to drop reporting this entirely in our next major ver as I think it does more harm than good. /cc @chancefeick @bdehamer |
Hey there,
so we just found some strange exceptions in our graphs. After digging into it, I found that actually when Rails
raise RecordNotFound, error
it will also appear in our graphs asrails.request.exceptions
which is somehow technically right.As you can see here
librato-rails/lib/librato/rails/subscribers/controller.rb
Line 23 in 139423b
exception
is:exception=>["ActiveRecord::RecordNotFound", "Couldn't find Design with 'id'=276"]
But then Rails answers the HTTP request with a
HTTP 404
which is again correct. But I do not have any other graph indicating exceptions. So what I miss is a way to graph all exceptions which actually cause our system to fail.Any ideas? Thoughts?
The text was updated successfully, but these errors were encountered: