naloveyuki/BitLogger
1
0
Fork 0
mirror of https://github.com/Nanaloveyuki/BitLogger.git synced 2026-07-29 14:06:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

📝 consolidate logger API and async lifecycle guidance

Browse Source
This commit is contained in:
Nanaloveyuki
2026-06-14 14:00:00 +08:00
parent 4f2ad097af
commit 265cd69ea9
154 changed files with 2419 additions and 396 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/api/library-logger-is-enabled.md
+10 -3
View File
@@ -3,7 +3,7 @@ name: library-logger-is-enabled
group: api
category: facade
update-time: 20260613
description: Check whether a LibraryLogger facade would accept a record at a given level.
description: Check whether a LibraryLogger facade passes the wrapped logger's min-level gate for a given severity.
key-word:
- library
- facade
@@ -35,8 +35,9 @@ pub fn[S] LibraryLogger::is_enabled(self : LibraryLogger[S], level : Level) -> B
Detailed rules explaining key parameters and behaviors
- This method delegates directly to the wrapped logger's `is_enabled(...)` behavior.
- It only checks logger-level severity gating; it does not evaluate sink filters or patch logic.
- The result reflects the current facade value, so derived facades with different thresholds can return different answers.
- It only checks logger-level severity gating through `min_level`; it does not evaluate later sink filters, patch logic, or any sink-side buffering/wrapping behavior.
- The result reflects the current wrapped logger state, so derived facades with different thresholds can return different answers.
- This check does not require unwrapping because it is part of the narrower library-facing surface.
- Use it when message construction or field gathering is expensive enough to justify a pre-check.
### How to Use
@@ -65,6 +66,8 @@ if logger.is_enabled(Level::Info) {
In this example, the check mirrors the same severity gate used by later write calls.
And a `true` result still means only that the level gate passed, not that the record is guaranteed to survive later sink-side filtering or routing.
### Error Case
e.g.:
@@ -72,8 +75,12 @@ e.g.:
- A `true` result does not guarantee final sink output if later filter logic rejects the record.
- If callers need broader composition helpers rather than just the level gate, they must unwrap first with `to_logger()`.
### Notes
1. This is a cheap severity check, not a full end-to-end delivery guarantee.
2. Prefer using it only when precomputing the log payload is meaningfully expensive.
3. Use `log(...)` or the severity shortcuts directly when no expensive precomputation needs to be avoided.