I have a Rails 3 app that is using the exception_notification gem to send emails about exceptions.
I would also like to show users specific error messages when exceptions occur, but by catching a generic Exception because I'm not sure of all the exceptions that can occur. I'm thinking the way to do this is to rescue from Exception, and then raise a custom exception. That way I'm still getting an email about the exception, and the user can see the custom exception's error page.
Does this sound like a Rails 3 way to do things?
Thanks a lot.
I think not.
As Ryan Davis says
Don’t rescue Exception. EVER. Or I will stab you.
More info about that statement here.
Rails 3.2 does exception handling in two middlewares:
ActionDispatch::ShowExceptions
ActionDispatch::DebugExceptions
You can check that one by running
$ rake middleware
ActionDispatch::ShowExceptions [source]
Used in production to render the exception pages.
ActionDispatch::DebugExceptions [source]
Used in development environment to render detailed stack traces when exceptions occur. Stops the middleware call chain and renders the stack trace if action_dispatch.show_detailed_exceptions is true to be more precise.
So the most simple way of doing something normal with this middleware would be monkeypatching the call method of ActionDispatch::DebugExceptions, doing all you need to do and then calling the original method.
The better way of doing this is, however, including your own middleware between those two. In it, you would wrap the call inside a rescue block and do your custom processing.
I am a maintainer of Airbrake and this is exactly what we're doing right now.
You might also want to check Errbit, the self-hosted alternative.
Related
Do exceptions that are filtered with a custom ExceptionFilterAttribute logged to Application Insights?
I want to return a custom DTO in my custom ExceptionFilterAttribute filter, but I think exceptions are no longer logged into ApplicationInsights after that. This is for .NET Core 3.0.
I added a line with:
this.telemetryClient.TrackException(context.Exception);
to make sure I can see the exception but I'm not sure if my exceptions are logged twice now.
Does anyone know if ApplicationInsights will log exception if they enter ExceptionFilterAttribute? I can't find documentation for this.
I'm calling just in case also:
base.OnException(context);
Does anyone know if ApplicationInsights will log exception if they
enter ExceptionFilterAttribute?
Yes, it will log the exceptions, so you do not need to add this line of code this.telemetryClient.TrackException(context.Exception);. Just using base.OnException(context); is ok.
You can see this GitHub issue for the similar issue, the reason is that "With new Ilogger enablement by default, exceptions are automatically reported by application insights.".
I also check it via a simple test, the test result as below:
Short and simple:
How to catch pgPL/SQL exceptions with QtSQL?
I haven't found any example or info at the docs.
More details:
I'm developing the front end for a system with Qt 5.3. The database perform some validation at some of the inputs and raise custom exceptions when something is invalid. What I want is to be able to handle these exceptions at he front end code, showing appropriate messages to the user.
EDIT:
I have tried to use the QSqlError class. Although it gave me the exception, it gave me too much data which will need to be parsed to be useful. Is there a way to get the exception raised without parsing the messages?
I'm writing a book on Rails 3 at the moment and past-me has written in Chapter 3 or so that when a specific feature is run that a routing error is generated. Now, it's unlike me to go writing things that aren't true, so I'm pretty sure this happened once in the past.
I haven't yet been able to duplicate the scenario myself, but I'm pretty confident it's one of the forgotten settings in the environment file.
To duplicate this issue:
Generate a new rails project
important: Remove the public/index.html file
Add cucumber-rails and capybara to the "test" group in your Gemfile
run bundle install
run rails g cucumber:skeleton
Generate a new feature, call it features/creating_projects.feature
Inside this feature put:
This:
Feature: Creating projects
In order to value
As a role
I want feature
Scenario: title
Given I am on the homepage
When you run this feature using bundle exec cucumber features/creating_projects.feature it should fail with a "No route matches /" error, because you didn't define the root route. However, what I and others are seeing is that it doesn't.
Now I've set a setting in test.rb that will get this exception page to show, but I would rather Rails did a hard-raise of the exception so that it showed up in Cucumber as a failing step, like I'm pretty sure it used to, rather than a passing step.
Does anybody know what could have changed since May-ish of last year for Rails to not do this? I'm pretty confident it's some setting in config/environments/test.rb, but for the life of me I cannot figure it out.
After I investigate the Rails source code, it seems like the ActionDispatch::ShowExceptions middleware that responsible of raising exception ActionController::RoutingError is missing in the test environment. Confirmed by running rake middleware and rake middleware RAILS_ENV=test.
You can see that in https://github.com/josh/rack-mount/blob/master/lib/rack/mount/route_set.rb#L152 it's returning X-Cascade => 'pass' header, and it's ActionDispatch::ShowExceptions's responsibility to pick it up (in https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/middleware/show_exceptions.rb#L52)
So the reason you're seeing that your test case is passing because rack-mount is returning "Not Found" text, with status 404.
I'll git blame people and get it fix for you. It's this conditional here: https://github.com/rails/rails/blob/master/railties/lib/rails/application.rb#L159. If the setting is true, the error got translated right but we got error page output. If it's false, then this middleware doesn't get loaded at all. Hold on ...
Update: To clearify the previous block, you're hitting the dead end here. If you're setting action_dispatch.show_exceptions to false, you'll not get that middleware loaded, resulted in the 404 error from rack-mount got rendered. Whereas if you're setting action_dispatch.show_exceptions to true, that middleware will got loaded but it will rescue the error and render a nice "exception" page for you.
I need some insights and thoughts about a refactoring I'm about to do to our web-app.
We initially used the session-per-request pattern with NHibernate and ActiveRecord by using the On_BeginRequest / On_EndRequest in the HttpApplication to create and dispose the session. Later on, we realized that any DB-related exceptions got thrown outside of our monorail-context, meaning that our rescues didn't kick in. As another sideeffect, we didn't have the option to fully skip creation of NHibernate sessions in any action, which in some cases would be desirable.
So we rewrote it to create sessions in Initialize() / Contextualize() in our base controller, and disposed them in the Dispose() of our base controller. We also Rollback the session in our rescue controller to prevent any half written changes to the DB. So far, so good. The reason for doing it in the Dispose() is because we want it to live through the view-rendering, because of lazy-loading reasons aswell as viewcomponents that needs to get a session (we could switch to units-of-work for the viewcomponents, but they don't seem to have a Dispose()...)
However, I'm experiencing some deadlock issues where we have started transacations in the DB that isn't getting rollbacked nor committed and I can't get my head around it, mostly because of the mess we've made with this approach...
So I found this article: http://hackingon.net/post/NHibernate-Session-Per-Request-with-ASPNET-MVC.aspx
And I thought, "Filters, we can use that in MonoRail too!", because it can kick in on BeforeAction and AfterRendering.
My questions then are:
What happens if an Exception occurs in the filter?
Will AfterRendering fire even if an Exception occurs in the action or the rendering?
Would you recommend this approach, if not, what are your suggestion instead?
Any pointers are very much appreciated!
You need an application error handler to care of exception handling.
Attach a debugger and find out.
Probably not (even though it is my article). It doesn't work with RenderAction. Best to use an IoC container to control the lifetime of connections.
Suppose I have a controller method like so:
#expose()
def search(self, title):
return dict()
Going to http://site/search/ will cause an exception to be thrown: TypeError: search() takes exactly 2 arguments (1 given).
The error is logical, but I'd rather handle it more gracefully. Is using *args or **kwargs the only way to avoid an error that I don't even seem to be able to catch?
EDIT: I guess I could always use title=None, but too much of that could get ugly...
Anyway, is there a way to catch the exception and/or handle argument mismatches more gracefully?
Thanks
The exception thrown at you for specifying an "incompatible" controller method signature only happens in debug / development mode.
You dont need to handle it more gracefully in a production environment, because once you disable development mode, controller methods send an HTTP 500 Error when they lack essential parameters.
You might want to consider the respective settings in your development.ini:
# WARNING: *THE LINE BELOW MUST BE UNCOMMENTED ON A PRODUCTION ENVIRONMENT*
# Debug mode will enable the interactive debugging tool, allowing ANYONE to
# execute malicious code after an exception is raised.
set debug = false
I hope this was your question.
In the case that you still want the controller do its work, even though its lacks important parameters, you must define default values, else the controller cannot do its work properly anyway.
The question you better ask yourself is: Do you simply want a nicer error message, or do you want the controller to be able to do its task. In the latter case, specifying default parameters is best practise, *args and **kwargs for each method just so the customer doesnt get an error is a very ugly hack in my option.
If you want to change the display of these errors refer to /controllers/error.py
Hope this helped,
Tom