tag:blogger.com,1999:blog-3237724005744642470.post5358321366362743632..comments2018-03-12T16:11:03.982+00:00Comments on Captain Debug's Blog: Spring 3 MVC Exception HandlersRoger Hugheshttp://www.blogger.com/profile/07042290171112551665noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-3237724005744642470.post-47743866086373926462012-07-01T10:16:48.688+01:002012-07-01T10:16:48.688+01:00Don This is an interesting problem, and given the ...Don<br />This is an interesting problem, and given the information provided, I think that in this case I’d tackle the problem by using your first possible solution of not using the @ExceptionHandler.<br /><br />The motivation for this approach is that I’d be differentiating between business exceptions and application exceptions. Just to clarify this: a business exception is just an alternate flow to the scenario you’re coding. In your case nothing appears to have gone wrong; a JpaSystemException has been thrown because the user isn’t allowed to remove the region as it’s still referenced by a country through an FK. This appears to be a normal alternate flow.<br /><br />An application exception, on the other hand, is when something goes wrong with the app: the database is down, there’s a coding issue that’s not been spotted in testing, it’s run of of memory etc. In this case I’d definitely opt for an @ExceptionHandler that would display a separate error page.<br /><br />It’s important, when designing an app, to differentiate between how you handle business exceptions and how you handle application exceptions and apply appropriate, but different paradigms. <br /><br />I think that in the case of a business exception it’s perfectly reasonable to use your try/catch approach to populate the model with a message that the JSP can pick up when it redisplays your detail page. <br /><br />Another reason for using the try/catch approach in this particular scenario is that the code appears simpler and easier to read, making it more maintainable.Roger Hugheshttps://www.blogger.com/profile/07042290171112551665noreply@blogger.comtag:blogger.com,1999:blog-3237724005744642470.post-36092059046682207342012-06-28T12:23:29.341+01:002012-06-28T12:23:29.341+01:00I have a question. I&#39;m not sure if @Exception...I have a question.<br /><br />I&#39;m not sure if @ExceptionHandler serves this purpose.<br /><br />All explanation can be found in my forum topic post:<br />http://forum.springsource.org/showthread.php?127846-ExceptionHandler-form-data-question&amp;p=417250#post417250<br /><br />I have a detail page where I have a remove button. If I click that remove button, and a FK constraint violation throws a JpaSystemException, I want a clean message to be displayed to the user ON the detail page instead of on a separate error.jsp<br /><br />In one way, using a submit button that also submits the object&#39;s ID, I can fetch the ID of the object from the request, and re-populate the model.<br /><br />But in another way, the object&#39;s ID is set on the URL using a @PathVariable. You cannot use @PathVariable in @ExceptionHandler methods.<br /><br />Do you use @ExceptionHandler methods for this? Or don&#39;t they supose to work this way?<br /><br />A solution to my problem is just catching the Exception in the controller&#39;s @RequestMapping annotated method itself, and handling it over there.<br /><br />But what then is the purpose of @ExceptionHandler?<br /><br />Thanks for your answer.Don Stevohttps://www.blogger.com/profile/13825726808327639595noreply@blogger.comtag:blogger.com,1999:blog-3237724005744642470.post-16108664826521141432012-06-28T09:04:46.224+01:002012-06-28T09:04:46.224+01:00OEF-Vet AliasedHacker Thanks for the comment and a...OEF-Vet AliasedHacker<br />Thanks for the comment and a good question. One of the points I was trying to make about the Spring MCV Exception handler paradigm is that it allows you to apply both fine and coarse grained tuning to your error handling, which means that you can target specific exceptions to specific code. Therefore if you know that, for example, an IOException will NEVER be associated with your database, then there&#39;s no reason why you can&#39;t access the database to provide really user friendly error pages.<br /><br />As I said in my blog, on of the problems to consider when writing an exception handler is to consider what happens if it throws an exception. <br /><br />I also have three other blogs in this series, which you may find useful:<br /><br /><a href="/2012/02/spring-3-mvc-exception-handlers-and.html" rel="nofollow">Spring 3 MVC Exception Handlers and Multiple Exception Arrays</a><br /><br />and<br /><br /><a href="/2012/02/spring-3-mvc-exception-handlers-and_14.html" rel="nofollow">Spring 3 MVC Exception Handlers and @ResponseStatus</a><br /><br />and<br /><br /><a href="/2012/02/using-springs-simplemappingexceptionhan.html" rel="nofollow">Using Spring’s SimpleMappingExceptionHandler</a>Roger Hugheshttps://www.blogger.com/profile/07042290171112551665noreply@blogger.comtag:blogger.com,1999:blog-3237724005744642470.post-72788594421733639682012-06-27T12:27:00.585+01:002012-06-27T12:27:00.585+01:00In your exception handling you are attaching the u...In your exception handling you are attaching the username as fetched from userdao to the page. What if userdao is the page in error? Your error page will not work.<br /><br />Thank you for the blog. It is interesting to see people code along the same lines of what you come up with on your on.OEF-Vet AliasedHackerhttps://www.blogger.com/profile/10454034426856725457noreply@blogger.com