>> >> Obviously, this means more work now and from time to time for adding >> such warning/error reports one by one. But that IMO pays off mid-to-long >> term. At the end we could have more time to fix "our" bugs :) >> >> What do you think? >> Thx >> Lukas > > I quite like idea. Something like assert call in C which check conditions and > if it failed then it log warning or raise exception depending on ENV variable. >
Unrelated, but something we adopted in 389-ds is not just to log warnings/errors, but to follow a formula of: 1: What went wrong? 2: Why did it go wrong? 3: How can you correct/remidiate this? That really helps compared to most errors which are just step 1, since there is now an actionable path for a user. For example, compare: Error: sync_read_entry_from_changelog - Retro Changelog does not provide entryuuid. This tells us something what went wrong, and a bit of why - but without knowing what the retro changelog is, or why entryuuid's are involved what should an admin do? Instead, our log message is now: sync_read_entry_from_changelog - Retro Changelog does not provide entryuuid. Check 'cn=Retro Changelog Plugin,cn=plugins,cn=config' contains 'nsslapd-attribute: entryuuid:targetEntryUUID' Now there is something actionable. The admin knows to check their cn=config, which section of that config, and what needs to be added to resolve the problem. So maybe this is something you could use in your warning/error improvements here? — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia
