I've read that wicket can't throw Checked exception. how to deal with this? What is a good way to implement exception handling in Wicket spring based application?
Mac
What do you mean, "Wicket can't throw". [citation needed] :)
Perhaps you read somewhere that wicket will not pass an exception to the servlet container in the default configuration?
I usually wrap specific components' methods with a try and change the page appropriately in catch, i.e. telling the user that something went wrong.
Update:
And also, you have the error(), warn() etc. in every Component which works with Feedback stuff. See here.
Related
I have a web application based on Apache Wicket. I have a problem with the usage of the method onBeforRender() of a web page. I need to use this method to intercept the creation of a page, and redirect the user to another page. If I use setResponsePage inside the onBeforeRender, the page is aniway rendered.
How Can I implement my desired behavior?
I think this should work:
throw new RestartResponseAtInterceptPageException(SomePage.class);
As it is an exception it should prevent any other code(=rendering) from being executed.
I'm not sure why you are redirecting. My guess is that it's an authorization topic. Then you might want to check out the IAuthorizationStrategy. It's described in the official Wicket docu. They have a very good documentation over there with lots of best practises and examples.
Which org.apache.wicket.settings.RequestCycleSettings.RenderStrategy do you use ? I believe your problem can happen only with org.apache.wicket.settings.RequestCycleSettings.RenderStrategy#ONE_PASS_RENDER.
Try to use #onInitialize() or #onConfigure() instead.
http://pastebin.com/5Nvn1uSB this is my xhtml
http://pastebin.com/fqwiRQER this is home there is the code for menuitems that dont work...
http://pastebin.com/Phun7EKS this is registration with connection to db... but doesn't work at all not even running it
Well, I see lots of issues here. First, your description of what's happening is non-existent. It's pretty hard to help you when all you provide is code without a good description of your environment, what you expect to happen and what's actually happening.
Also, it would be helpful to know what steps you have already taken to debug your code.
That said, based on a quick read of your code, your p:commandButton is using an actionListener instead of an action which I believe is the correct attribute.
Lastly, you're using raw text fields from your web page to directly build an SQL statement. This opens you up to all kinds of code injection exploits that you probably want to avoid. You'd be better off using something like JPA as an abstraction layer that allows you to persist objects.
I am confused with the following question:
You are implementing a model component. You realize that an IOException might arise if you lose connection to the database. Following are the option:
Implement multipathing to provide redundant connectivity to the database, thereby avoiding that risk of connection failure.
Provide an error handler page, and use the page directive in the invoking ISP to redirect to that page if the error arises.
Use the JSTL tag to take control if the exception arises.
Surround the problem area with a try/catch block and implement appropriate recovery or fallback behavior.
I think answer is option no 4 but it's written answer is 3 i don't know how?
IMO, the assumption is once an IOException is thrown, there is no way to reconnect to the database, hence you are left with JSTL, the view component, to display the appropriate error message.
I have a a misbehaving calling application which I dont have the source for, which confronted with a non 200 http status- quietly logs an error/information message...
I need to be able to make it actually exit with some kind of error message. happen to know that it does catch some exceptions.... so this is my strategy
replace some part of the http client code with one that throws an exception and then let the exception bubble up to this app, where upon I expect it to exit...
Is there any other way/better to do this ? if not better simply suggestions of alternatives also welcome.
Thanks
That seems like a reasonable approach. You could also try using an aspect - if you use load-time weaving, you can add aspects to the client application at the point where you want it to throw an exception (though without the source code it will be tricky to work out the exact pointcut).
For example: we have WebApplication based on MVC. Also, for this app we are used: Spring, Struts 2 and Hibernate frameworks.
Lets go look on small scenario: user try save some instanse, for example: BO Book.
So, user fill form fields and send request to the server:
What happened on server?
Execute action method Action.Save();
Inside Action.Save() call Service.save();
Inside Service.save() call DaoHibernate.save();
Inside DaoHibernate.save() call getHibernateTemplate().save();
Method getHibernateTemplate.save() - it is framework implementation, so we cant access to this method. We only know, that if something fail inside this method throws DataAccessException.
So, at this moment I think, how correct implement my logging and error handling?
On which level?
On Dao level? Service level?
Or on level Struts actions?
What do you think about this?
Or need on each level?
What best practices you can recommended?
Here is your architecture:
How do you want to handle the error on DAO layer? Return fake data? Empty collection? if you can't, just let the exception pop-up.
And how about handling on the service layer? You know that the database is not working, so what can you return to the Struts action? An empty result? An error object? Isn't exception an error object?
So the exception appears in the Struts action. Here you have some options. If the exception will actually tell something to the user and your GUI is prepared, you can return different view (and log the exception here).
But what if you catch a NullPointerException in Struts action? Will you handle it separately in every Struts action? No, so pass the exception even further (!)
I think you get the idea - as long as you don't know how to handle the exception (and logging is not handling), let the client clean-up the mess. Otherwise you are only hiding the problem and increasing the damages (e.g. transactions aren't rolled-back, users see incorrect results).
I would advice implementing generic exception handling mechanism which logs the exception and returns HTTP 500 to the user. Gentle error message (without stack trace) should appear and the user should be apologized. You should investigate every error that reaches this layer.
As far as I remember Struts (and virtually every web framework) has some centralized way of handling exceptions. (Struts 2 Exception Handling Docs)