BitLogger/docs/api/configured-logger-file-reopen-with-current-policy.md

name, group, category, update-time, description, key-word

name	group	category	update-time	description	key-word
configured-logger-file-reopen-with-current-policy	api	runtime	20260512	Reopen the file sink behind a configured runtime logger using its currently stored runtime policy.	logger runtime file public

Configured-logger-file-reopen-with-current-policy

Reopen the file sink behind a ConfiguredLogger using the currently stored runtime policy. This helper is useful when callers want recovery behavior without supplying a one-off append override.

Interface

pub fn ConfiguredLogger::file_reopen_with_current_policy(self : ConfiguredLogger) -> Bool {}

input

• self : ConfiguredLogger - Config-driven runtime logger whose file sink should be reopened with current policy.

output

• Bool - Whether reopen succeeded.

Explanation

Detailed rules explaining key parameters and behaviors

• Plain file sinks reuse their current stored reopen policy.
• Queued file sinks forward reopen behavior to the wrapped file sink.
• This helper differs from file_reopen(...) because it does not accept a per-call append override.
• Non-file sinks return false.

How to Use

Here are some specific examples provided.

When Need Policy-preserving Recovery

When a file sink should be reopened without changing runtime append behavior:

ignore(logger.file_reopen_with_current_policy())

In this example, recovery reuses the runtime policy already stored on the sink.

When Separate Recovery From Policy Mutation

When append mode should be controlled elsewhere:

let ok = logger.file_reopen_with_current_policy()

In this example, reopen is explicit while policy mutation stays separate.

Error Case

e.g.:

• If the configured sink is not file-backed, the method returns false.

• If callers want to change append behavior during reopen, file_reopen(...) or file_reopen_append() / file_reopen_truncate() are better APIs.

Notes

1. Use this helper when recovery should respect the currently stored runtime policy.

2. It is clearer than passing no override through a more general reopen API.