Very sorry, I meant to send that to the list as well. -Spiros E.
On Sat, Oct 24, 2015 at 10:55 AM, Daniel Bünzli <[email protected] > wrote: > > Spiros sent this. I respond on the list I hope he doesn't mind. My > response is below his message. > > > Le samedi, 24 octobre 2015 à 14:45, Spiros Eliopoulos a écrit : > > > > 1) nop reporter (do absolutely nothing) > > > 2) stderr reporter (vomits on stderr) > > > 3) invalid reporter (throws in your face) > > > > It should be #2. Ideally, adding logging to a program would not change > its behavior at all. Obviously not the case in practice but that's the > goal. Adding a logging dependency and (for example) logging the fact that a > program started should still run the program. Adding a library dependency > that includes unconfigured loggging calls should also still run the > program. Throwing an exception is about as big of a deviation from normal > program behavior that you can get. It should not be #3. > > > > While unmodified program behavior is the goal, that's of course not > feasible in practice for the very reason that logging modifies the program. > It adds new lines of code which adds new computation, be it just NOOP > function calls. More importantly though, the addition of logging calls is > an attempt to collect diagnostic and progress information by the > programmer, and report it to the user. Their very presence suggests that > they're important, so the information they collect should not be discarded > unless there is an explicit request to do so. It should not be #1. > > > > Stderr was quite literally invented for reporting errors and diagnostic > information without cluttering stdout[0]. It should be #2. > > > > -Spiros E. > > > > [0]: http://www.spinellis.gr/blog/20131211/ > > I disagree that "ideally adding logging to a program would not change its > behaviour at all". I think you are mixing program instrumentation and > logging. Logging by summarizing computation is a creative act and has an > effect on the program output that cannot be ignored; in an interactive > program it may even trigger a feedback command from the user to the program > so for me logging *has* to part of the program behaviour. Which invalidates > for me your argument that it should not be 3). > > My concern with 2) is that's it is equivalent to either 1) or 3) when the > concept doesn't exist (e.g. on bare metal) and I prefer consistent and > visible behaviour regardless of context; this is why I lean towards 3). > > Best, > > Daniel > > > > >
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
