• Post Reply Bookmark Topic Watch Topic
  • New Topic

Optionally catch an exception IF it's not going to be caught by calling routine?  RSS feed

 
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I want to write classes with methods that perform JDBC operations that throw SQL exceptions. For many of the methods, I'd ideally like to be able to have them catch exceptions and just send them to a standard Logging system "IF" the code that calls the methods is not going to catch the same exception. However, I'd like the "option" to have code that calls these methods catch the same errors if I want to but not "Require" the calling routines to catch them.... so I don't want to declare the methods with a "throws" that would require all calling code to Try/catch.

For some background, the logic behind what I'm looking to do is that there will be lots of places where these classes and their methods may be used where the code is basically "throw away" scripting code where just having error logs generated is more than sufficient. However there are also places I want to use the same classes/methods that I would want to handle the exception differently. So, for at least half the places I want to use these methods, there's no good reason to require cluttering the calling code with Try/catch, but when I DO want to handle the exceptions, I'd like them to get passed up to the calling routine so I can handle them in a way that is appropriate for the calling routine. Does that make sense?

I guess I'm kind of looking for is the ability to "override" the catch of a called method "IF" I want to but to treat the method as though it doesn't throw any exception "IF" I don't want to override the called routines catch logic.

Is this possible?
 
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tom Malia wrote:Is this possible?

Possibly, but it sounds like over-engineering to me. Just create two methods:and:(BTW, 'Error' above means java.lang.Error)

There are almost certainly many other ways to do it, but that seems the most "obvious" to me.

Main point: Do NOT simply log the Exception and continue. Either the exception is fatal, in which case you MUST terminate, or it can be dealt with; but either way you should have a strategy in place.

Winston
 
Tom Malia
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks,
I was thinking about creating multiple methods but wanted to make sure I wasn't missing a possible language feature that might give the same result. Also, I had some kind of mental block about multiple methods... I had it stuck in my head that the methods would need different names.... don't know why the different signature, by having a Logger parameter didn't dawn on me but I'm certainly grateful to you for making that solution so obvious in hindsight!

Thanks!
 
Marshal
Posts: 56600
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should be thinking where it is best to catch the Exception. If you can deal with it in the current method and sort out the problem, then catch it there. If not, declare that it is thrown. If, as Winston says, you cannot deal with it at all, it will have to propagate and terminate the application.

You should not throw and catch the same Exception in the same method. Don't log the Exception and re-throw it. That simply risks logging the Exception twice.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tom Malia wrote:don't know why the different signature, by having a Logger parameter didn't dawn on me but I'm certainly grateful to you for making that solution so obvious in hindsight!

Like they say on 'Jeopardy': It's only easy when you know the answer.

Glad it helped.

Winston
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!