Skip to main content
Code Review

Return to Answer

deleted 3 characters in body
Source Link
Malachi
Malachi
  • 29k
  • 11
  • 86
  • 188

In addition to all the valuable point so far: You specifically asked about robustness. There is one thing that you did not seem to consider:

Concurrency!

(rolfl mentioned it indirectly in his answer while I was writing this answer. I thought about omitting my answer, but ... this just fittedfit perfectly :) )

When multiple threads are accessing the same logger instance concurrently, you may end up with garbage in your log file.

Of course, you could simply make your writeToFile method synchronized, but this is a large hammer for a tiny nail. Solving this properly is not so trivial. The java.util.logging loggers internally use lock objects and some synchronized methods, e.g. in the StreamHandler#publish(Record) method to alleviate this problem (note that here the synchronization only takes place in a handler, which is not necessarily called for each and every log call, and only in the implementations that actually need the synchronization).

In addition to all the valuable point so far: You specifically asked about robustness. There is one thing that you did not seem to consider:

Concurrency!

(rolfl mentioned it indirectly in his answer while I was writing this answer. I thought about omitting my answer, but ... this just fitted perfectly :) )

When multiple threads are accessing the same logger instance concurrently, you may end up with garbage in your log file.

Of course, you could simply make your writeToFile method synchronized, but this is a large hammer for a tiny nail. Solving this properly is not so trivial. The java.util.logging loggers internally use lock objects and some synchronized methods, e.g. in the StreamHandler#publish(Record) method to alleviate this problem (note that here the synchronization only takes place in a handler, which is not necessarily called for each and every log call, and only in the implementations that actually need the synchronization).

In addition to all the valuable point so far: You specifically asked about robustness. There is one thing that you did not seem to consider:

Concurrency!

(rolfl mentioned it indirectly in his answer while I was writing this answer. I thought about omitting my answer, but ... this just fit perfectly :) )

When multiple threads are accessing the same logger instance concurrently, you may end up with garbage in your log file.

Of course, you could simply make your writeToFile method synchronized, but this is a large hammer for a tiny nail. Solving this properly is not so trivial. The java.util.logging loggers internally use lock objects and some synchronized methods, e.g. in the StreamHandler#publish(Record) method to alleviate this problem (note that here the synchronization only takes place in a handler, which is not necessarily called for each and every log call, and only in the implementations that actually need the synchronization).

Source Link
Marco13
Marco13
  • 831
  • 4
  • 8

In addition to all the valuable point so far: You specifically asked about robustness. There is one thing that you did not seem to consider:

Concurrency!

(rolfl mentioned it indirectly in his answer while I was writing this answer. I thought about omitting my answer, but ... this just fitted perfectly :) )

When multiple threads are accessing the same logger instance concurrently, you may end up with garbage in your log file.

Of course, you could simply make your writeToFile method synchronized, but this is a large hammer for a tiny nail. Solving this properly is not so trivial. The java.util.logging loggers internally use lock objects and some synchronized methods, e.g. in the StreamHandler#publish(Record) method to alleviate this problem (note that here the synchronization only takes place in a handler, which is not necessarily called for each and every log call, and only in the implementations that actually need the synchronization).