feat: create the logger, wired to nothing, and watch it say so - #51
Conversation
|
@coderabbitai review |
|
Note Reviews pausedUse the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (6)
📝 WalkthroughWalkthroughThe PR adds a ChangesLogger startup
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to The logger wiring change has no actionable merge-blocking risk remaining and is merge-ready after normal checks and review. Sequence Diagram(s)sequenceDiagram
participant Application
participant Syslog
participant SolidSyslog
Application->>Syslog: Syslog_Start()
Syslog->>SolidSyslog: SolidSyslog_Create(Buffer unset, Sender unset)
SolidSyslog-->>Syslog: Return logger handle
Syslog-->>Application: Store logger handle
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
✅ Action performedReview finished.
|
0b1af20 to
c481c5c
Compare
|
@coderabbitai pause |
The logger is created with both collaborators absent, deliberately. Create never fails and never returns NULL — a missing collaborator is substituted with its Null object — so the only evidence is what the handler prints, and the run report now carries three of them: [syslog] CRITICAL SolidSyslog bad-config (detail 1) [syslog] CRITICAL SolidSyslog bad-config (detail 2) [syslog] CRITICAL SolidSyslog bad-config (detail 3) Flash +1,052 B RAM +184 B One each for the buffer, the sender and the store, named in Detail as values of the emitting class's own error enum. Doing it in this order is the point. An integrator who wires everything at once and sees nothing cannot tell a working logger from a silent one; seeing the faults first, and then watching them go quiet as collaborators arrive, is the difference between believing it works and knowing. NULL is "not supplied" and is reported. A collaborator deliberately done without is passed as its Null object instead — the library tells those two apart, and so should anyone reading this wiring later. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
9c080cf to
0fbdfab
Compare
✅ Action performedReviews paused. |
Create the logger with both collaborators absent, deliberately, and read what the handler prints.
No
_Createfails or returnsNULL— a missing collaborator is substituted with its Null objectand reported — so the only evidence is what the handler says:
Three, for the buffer, the sender and the store. Each names the collaborator in
Detail, as avalue of the emitting class's own error enum.
The order matters. Wire everything at once and see nothing, and you cannot tell a working logger
from a silent one. Seeing the faults first, then watching them go quiet as each collaborator
arrives, is the difference between believing it works and knowing.
A convention worth adopting now:
NULLas a parameter means "not supplied" and is reported, whilea collaborator you have deliberately done without is passed as its Null object. The library
distinguishes the two, and so should anyone reading the wiring later.
Syslog.cis introduced here as the one place that knows how the logger is assembled; every laterstage adds to it, and nothing else in the application ever sees a config struct.
Summary by CodeRabbit
New Features
Documentation