I'm developing a grails plugin that among other things it handles the json render of all responses for our REST APIs. We are handling some common response status as exceptions, such as bad requests, forbidden, etc.
By throwing specific exceptions I then process them in an error controller and set the proper response status.
The preblem We are having is that since We are monitoring our APIs through NewRelic, all exceptions are reported as 500 errors.
I saw that in grails 2.3 you can define exception handlers on the cotrollers, and it works, but defining it one by one is out of the questions, and adding the handler through metaClass is not working.
Any ideas to solve this?
I am not sure what you mean by "defining it one by one is out of the questions" but if you mean that you don't want to add the exception handler methods in all of your controllers you have at least a couple of options. One is that you could define the exception handler methods in a base controller which all of your other controllers extend. Another option is to write an AST transformation which adds the methods to all of your controllers at compile time.
I hope that helps.
Related
I have been searching the web for the issue I'm facing for quite some time now. I found people facing it, but couldn't get an appropriate solution to the problem. The issue is what would be the best way to handle any exception occurred in an template.gsp ? I know I can use a try-catch there so that my controller don't get the exception, but I did find people saying its not a good practice, but failed to answer why. So is it a wrong way and if it is then is there any better solution to deal with this problem ?
The correct way is with a 500 error handler: http://grails.org/doc/latest/guide/theWebLayer.html#mappingToResponseCodes
If you have a lot of logic in your views that could produce a error consider refactoring the code into a tag library which can incorporate better error handling
It depends on what behavior you want for your application with the error.
If a generic error page works for the application - then setup an error page in URL mappings and ignore the error in the controller.
Do you need a nice custom error that is specific for that case - (or possibly display an alternate page? ), if so then you'd need to a try catch (or do some fun with URL mapping and creating an error controller). The objections that come up in Exception handling in Grails controllers arise around the amount of code required for the error handling in the controller vs the rest of the application - with the error handling code being ~40% of each controller method. This causes the code to seem bad/bloated (and apparently violate the CodeNarc "CatchException" rule).
Can anybody tell me the best approach of handling exceptions in Struts2? I've configured global exception mappings in struts.xml for specific exceptions. I couldnt find the best approach of handling exceptions.I have two approaches in mind.
1) putting try/catch in each method and throwing exceptions from catch block 2)Without catching any exceptions ie., declaring exceptions in throws clause of method so that Framework automatically handles exceptions and picks suitable mapping from struts.xml and displays the respective error page.
If anybody knows or has tutorial link on this exception handling, pls provide me.
Catching and subsequently rethrowing an exception is almost never a good idea. Typically, you only want to have try/catch blocks if there is actually something you can do with the caught exception, such as handle it and move on correctly, or adding additional information to the exception.
Adding throws to a struts method is perfectly acceptable, in the event that what it throws is not something you can handle in your code and you just need to display an error page. Unless there is some gain to the overhead of the try/catch, it is better just to let it unwind on out on it's own.
I'm doing BDD on an MVC3 project with SpecFlow. My current specification scenario says that:
Given a user is working on the system
When an error is raised
Then the user should be redirected to error page
And display a link to go back where he came from
How can I test a spec like this? I usually test the controller directly, however the Error view given by the standard MVC3 template has no controller, and no controller is used, because is redirected by the HandleError global filter.
In exceptional cases I use Watin to test that the behavior conforms to what the specification says, however to do that I need a view that raises an error, something that when everything is working i do not have.
Any ideas on testing scenarios like this?
I have a few thoughts on this scenario:
1.) "Given a user is working on the system" is a pretty vague step. What code would be found in the step definition? Unless you have a user class that has a WorkingOnSystem method, it might be worth taking this line out.
2.) Without having seen the rest of your code, I think the target of this feature should be the HandleError filter itself. By its very definition, you know that when it is invoked an error has occurred. All you need to do is instantiate the filter, call the appropriate method, and test the results.
Think about it this way: What does "When an error is raised" mean in your system? If your HandleError filter is not the place, then you probably don't have a place. In which case, you'll need to be more specific.
I think the awkwardness around this spec is due to ASP.Net MVC. When you're dealing with a framework of abstractions, you're sometimes left to "wrap" your specs around some part of it. We just can't go end-to-end easily when the parts of the application come from so many places.
I am in the process of making sure our MVC app catches all exceptions and reports them to us so we can stay on top of the errors. I already learned that I need some code in the Global.asax Application_Error event to catch exceptions that never make it to the Controller, and that in our custom base Controller we override the OnException() method and that seems to work for Controller exceptions. What I am wondering is will View exceptions fall back to that or is there some other thing I need to implement to catch all those?
Ryan, we have solved this by implementing ErrorAttribute in our Custom Controller Base Class (so that we only put it once in the whole application), this way the users won't see the nasty Yellow Screen of death.
To log unhandled error I'd suggest using ELMAH as a logging error solution, it is VERY unobtrusive (just configuring the web.config) and it has a very nice interface to filter, search and you can even subscribe to it by RSS.
Good Luck!
So we have a base controller we are using and it contains an override for OnException that logs the error to our bug tracking tool. However I noticed that some errors never make it, and I'm wondering if it is somehow silly to expect an application to log all it's own errors when itself is the thing that is having an error, which could cause some errors never to be caught.. ? Either way what is the best solution, or should OnException always be expected to happen? Should I be putting some tool on Windows Server to log the errors instead of within the app itself?
I don't think I've ever seen an error that wasn't trappable at some point. I have application level logging also and like you i've implemented a base controller.
my base controller doesn't do any logging. instead i created a custom action filter with which i decorate my controllers and actions with and it does all the logging.
i also, in the global.asax, added code to the Application_Error event that does a bit of logging and also calls an error controller to handle the actual error.
I hope this in some way helps you. If you want any of the code i've mentioned then add a comment to this answer and i shall provide. it's not a lot of code either.
The Controller.OnException event can only catch events that are thrown in the scope of an executing Controller. There are events that happen before an http request is mapped to a controller and the OnException event will not capture these events. For example, if you have a controller factory that maps the RequestContext to a particular controller, than an exception thrown here is not in the scope of a Controller.
You should implement a "fail safe" exception handler in the global.asax.Application_Error event.