• Post Reply Bookmark Topic Watch Topic
  • New Topic

Catching runtime information during exceptions  RSS feed

 
Nitin Dubey
Ranch Hand
Posts: 126
Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have been thinking about capturing run time data that lead to exceptions. The exceptions like Divide by zero, array index out of bounds, null pointer exceptions occur in practical scenarios and one has to go back to log files, then find data and then start working on it.

However, I feel one can write code in the following manner and identify the actual problem with data which will help in identifying the root cause easily. Though approach to catch Exception just for logging is reported as anti-pattern, I am of an opinion that this will eventually help in root cause identification easily.



>
 
Campbell Ritchie
Marshal
Posts: 56598
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An Exception object usually contains information about the runtime error which caused it. If you write your own Exceptions you can of course add information.
Beware of logging an Exception and re-throwing it. You may find the same Exception is logged twice. You would need special proecautions ot prevent that.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As long as the message gets logged somehow you'll be able to track it down. RuntimeExceptions should definitely be allowed to bubble up, so it's good that you're rethrowing them. However, it's kind of pointless to explicitly catch/log/rethrow unless you're adding useful information, or you have good reason to believe that higher up the chain it won't get logged.

Also, if you're doing to do this, don't catch Exception. Instead, catch RuntimeException, and then catch the checked exceptions (if any) separately.
 
Nitin Dubey
Ranch Hand
Posts: 126
Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
-- Yes catching RuntimeException is a better idea, thanks for pointing it out Jeff
-- I can catch RuntimeException and throw a subtype of RuntimeException (application specific) that can record whether it was logged or not. Hence, multiple logging issue should be resolved.
-- I would be printing the objects that are in question when exception occurs. Hence, the exception log will have entire serialized object in XML form so that one can rebuild the object if required. In all cases one needs to reproduce the problem first and they need data. At times it becomes difficult to debug the problem if you are not sure about the data that was either passed by the user OR was being processed at that right moment

Does it sound good enough?
 
Nitin Dubey
Ranch Hand
Posts: 126
Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Any suggestions?
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nitin Dubey wrote:Any suggestions?

I think you need to come up with a set of clear and specific expectations of what you're trying to do. Right now it all seems a bit "woolly".

NullPointerException's, for example, are often the most pernicious to try and track down, but this is generally because they are an effect, not a cause; and as far as I'm concerned, the best way to avoid a lot of needless searching is by good technique (proper parameter checking, avoiding returning nulls, etc, etc) so that exceptions occur as close to the point of cause as possible. Good messages (including runtime information if needed) can also help to pinpoint cause as well.

The problem is that you don't always have control over the code that's written, and this is where your MessageLogger may have some merit. I just think you need to be absolutely clear about what it's intended to achieve.

HIH

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