On Fri, 2009-11-06 at 16:16 +0100, Denys Vlasenko wrote:
> Also in looking at several plugins, I've noticed that
different plugins
> have different policies for reporting errors, warnings, informational,
> and debugging messages. Sometimes exceptions are used, sometimes calls
> to 'update_client' and sometimes calls to 'log'. Is there a
> pattern/policy that I just haven't figured out yet, or is this still in
> flux?
It's in flux, and it used to be much worse than how it looks now.
exceptions were there before my time. I don't like them.
Maybe remove?
currently, we have:
log(fmt...) just writes to the log (stderr / syslog / dev/null,
depending on the application's setup)
error_msg(fmt...) the same as log, but semantic is that this is
an _error_, not just random bit of info
[p]error_msg[and_die] == [append errno string to] error_msg [and die].
update_client(str) send this string to client over DBUS
(for logging or display by clients)
warn_client(str) send this string to client over DBUS.
This is an error message.
Plans:
Minimum: make warn/update_client() take printf formats.
I am thinking about making XXXerror_msgXXX automatically do
warn_client(). There is rarely (never?) a situation where we
have an error we wish to log on server side, but _dont_ want
to let client know about it.
log() will log only on server side - used for debugging, thus
not a good idea to swamp clients with these msgs.
update_client() will perhaps remain, it does not map nicely
to log() or error_msg().
It is committed to git now.
--
vda