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