As a developer, often I'd like to start recording some diagnostic information about the performance and progress of an algorithm being performed by a single thread, possibly traversing multiple objects/methods, logging the said diagnostic information if and only if some particular condition is satisfied.
Instead if creating a new logger and/or logging this information everywhere, the concept of an auto-closeable ThreadLocal resource, ie: DiagnosticsRecorder, that can be encapsulated within a try-with-resources-block (and thus auto-closed/logged) would simplify development and reduce logging code.
For example:
try(DiagnosticsRecording diagnostics = DiagnosticsRecording.create("Undeploy"))
{
//... do some work ...
diagnostics.add("Undeployed", file);
}
Upon closing the DiagnosticsRecording, the recorded information would be logged to the provided logger (or default if not provided).
Should an algorithm invoke another method, that method may "continue" with the outer recording.
try(DiagnosticsRecording diagnostics = DiagnosticsRecording.continued())
{
//... do some other work ...
diagnostics.add("Connected to", connection);
}
Alternatively, the other method may create a new "section" in the outer recording.
try(DiagnosticsRecording diagnostics = DiagnosticsRecording.section("Backup"))
{
//... do some other work ...
diagnostics.add("Backed up to", location);
}
Importantly this approach allows developers to focus on instrumenting code, without adding any new parameters or state to existing classes. Simply creating a try-with-resources-block containing a suitable DiagnosticsRecording is all that is required.
As a developer, often I'd like to start recording some diagnostic information about the performance and progress of an algorithm being performed by a single thread, possibly traversing multiple objects/methods, logging the said diagnostic information if and only if some particular condition is satisfied.
Instead if creating a new logger and/or logging this information everywhere, the concept of an auto-closeable ThreadLocal resource, ie: DiagnosticsRecorder, that can be encapsulated within a try-with-resources-block (and thus auto-closed/logged) would simplify development and reduce logging code.
For example:
Upon closing the DiagnosticsRecording, the recorded information would be logged to the provided logger (or default if not provided).
Should an algorithm invoke another method, that method may "continue" with the outer recording.
Alternatively, the other method may create a new "section" in the outer recording.
Importantly this approach allows developers to focus on instrumenting code, without adding any new parameters or state to existing classes. Simply creating a try-with-resources-block containing a suitable DiagnosticsRecording is all that is required.