Improve logging of failed roster updates


Only an SQL exception is logged, this does not really help to identify the root cause. Would you please review the patch.




Guus der Kinderen
January 2, 2012, 7:17 PM

I have just checked in an improvement to the exception logging, which was the original problem tackled in this issue.

I've chosen to not change the method interface just for logging purposes (by adding a username). Instead, I'm now logging a message that includes all parameters that are actually being used in the query (of which one is likely to be erroneous if an exception message is to be logged). Although this data doesn't tell you exactly who is affected, it does provide better details in exactly what failed.

Guus der Kinderen
January 2, 2012, 7:05 PM

The only added benefit that I can see from closing the prepared statement before executing the insertGroups() call is that there's one less database resource open. But as the database connection itself is not closed until later anyway, I can't see how this makes much of a difference.

Guus der Kinderen
January 2, 2012, 7:03 PM

I doń't particularly like this patch. My primary concern are these additions:

The comment implies that the the similar (but more complete) close statement in the finally blocks executes only after a garbage collect occurs. This is untrue. Statements in a finally block will always* be executed directly after the statements of the try and/or catch blocks have been executed. Perhaps the original author was thinking of the behavior of the Object#finalize() method?

* Untrue if the JVM is shut down - but Object#finalize() won't help there either.

Your pinned fields
Click on the next to a field label to start pinning.


Guus der Kinderen