BitLogger/docs/api/configured-logger-file-reopen.md

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

name	group	category	update-time	description	key-word
configured-logger-file-reopen	api	runtime	20260512	Reopen the file sink behind a configured runtime logger with an optional append-mode override.	logger runtime file public

Configured-logger-file-reopen

Reopen the file sink behind a ConfiguredLogger. This helper is useful for recovery flows after file unavailability or policy changes.

Interface

pub fn ConfiguredLogger::file_reopen(self : ConfiguredLogger, append~ : Bool? = None) -> Bool {}

input

• self : ConfiguredLogger - Config-driven runtime logger whose file sink should be reopened.
• append : Bool? - Optional append-mode override used for reopen behavior.

output

• Bool - Whether reopen succeeded.

Explanation

Detailed rules explaining key parameters and behaviors

• Plain file sinks reopen directly.
• Queued file sinks forward reopen behavior to the wrapped file sink.
• append=None preserves current reopen policy, while Some(true/false) overrides append mode.
• Non-file sinks return false.

How to Use

Here are some specific examples provided.

When Need Recovery After File Failure

When application code should attempt to restore file logging:

ignore(logger.file_reopen())

In this example, the configured logger tries to reopen its runtime file sink using current policy.

When Need Explicit Append-mode Reopen

When recovery should choose append or truncate behavior explicitly:

let ok = logger.file_reopen(append=Some(true))

In this example, reopen behavior is directed by the call site.

Error Case

e.g.:

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

• If callers only need the current configured policy, file_reopen_with_current_policy() may be the clearer API.

Notes

1. Use this helper for explicit recovery flows.

2. Pair it with file_available() and failure counters when diagnosing reopen behavior.