• Post Reply Bookmark Topic Watch Topic
  • New Topic

Exception throwing  RSS feed

 
Andrew Cane
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
my code structure is as follows:




This is the doGet method from the controller


Notice the throws clause in interface, and doGet() and doSomething () method. Is this the recommended exception handling in servlet architecture? I don't intend to handle any of those exceptions. I just want to keep passing the exceptions all the way to the bottom stack, but I don't want to lose any of the stack trace on the way (for logging purposes).
thanks
 
Raymond Tong
Ranch Hand
Posts: 255
2
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You may catch it, log the exception and rethrow it.
http://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html#rethrow
 
Andrew Cane
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would never catch it. So if this is the case,
1. what should be declared in the throws part of the interface? should the interface throw all those specific exceptions, or just throws Exception would be fine?
2. what should be put in the doGet method or any controller that calls doSomething()? all those specific exceptions, or just throws Exceptions would be fine?

as you can see, doSomething may call various other methods which may throw their own specific exceptions. The case right now is everytime I modify doSomething() by adding calls to additional methods, these methods are very likely to throw their own exceptions. When this happens, I need to add those exceptions to the throws caluse of doSomething(), and of course, I would need to add those exceptions to the interface and to all methods that calls doSomething(). What is the best practice for this case? and I don't want to catch (handle) those exceptions. I'll just log it for diagnostics later, when the exception has reached the bottom most method stack (before getting to jsp, so I guess that would be controllers). And of course, I don't want to lose any information during the exception passing.
thanks.
 
Raymond Tong
Ranch Hand
Posts: 255
2
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why would catch exception, log it and re-throw it not possible for your case?
Catch the exception doesn't mean you have to handle it, you could just log it and re-throw it to the caller to handle it.

Otherwise, you may use AOP to intercept the exception and log it.
http://www.eclipse.org/aspectj/doc/next/progguide/semantics-advice.html
 
Campbell Ritchie
Marshal
Posts: 56553
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raymond Tong wrote: . . . log it and re-throw . . .
Log and rethrow? Doesn't that risk having the same Exception logged several times?
 
Marshall Blythe
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's good that you're really thinking about exception handling. I normally follow the advice in this article: Effective Java Exceptions. I model my exceptions so fall into one of 2 categories:

  • Faults
  • These represent unplanned conditions that can only be expressed in terms of implementation details. These include programming errors and system failures such as remote resource connectivity failures. The caller will generally have no strategy for coping with these kinds of exceptions- other than perhaps retrying connectivity failures. They are best represented as unchecked exceptions.
  • Contingencies
  • These represent expected conditions that can be expressed in terms of the method's intended purpose. The caller of the method expects these kinds of conditions and has a strategy for coping with them. For example, a user tried to initiate a sale on a closed cash register, or the user tried to withdraw funds from an account with an insufficient balance. They are best represented as checked exceptions.

    With this exception model in place I can add one or more fault barriers situated near the application entry points (i.e. near the top of the call stack). For a typical web application I normally implement a single fault barrier with a Filter at the beginning of the filter chain. You can do all of your fault handling (e.g. logging, notifications, alerting) within the barrier.

    Take a look at that article to see if it gives you some ideas.
     
    Campbell Ritchie
    Marshal
    Posts: 56553
    172
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Marshall Blythe wrote: . . . I normally follow the advice in this article: Effective Java Exceptions. . . .
    That is a good article. I like it that it assumes one will build in error‑handling from the beginning.
     
    Andrew Cane
    Ranch Hand
    Posts: 91
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    okay, I'll read the article tonight. As of now, I got another exception related issue. when throwing runtime exception to jsp, my error page didn't get invoked. I'm using the error page directive. Am I missing something?
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!