Forums Register Login

Catching runtime information during exceptions

+Pie Number of slices to send: Send
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.



>
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
-- 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?
+Pie Number of slices to send: Send
Any suggestions?
+Pie Number of slices to send: Send
 

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
I AM MIGHTY! Especially when I hold this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 656 times.
Similar Threads
Telephonic Interview
Writing all errors ever occuring to file
How to work with try-catch in servlets
Why so many Exception Handling classes ?
Documet object is returned null
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 06:25:52.