On Thursday, 11 September 2014 at 16:55:32 UTC, Marco Leise wrote:
>
> 3. Exceptions and loggin don't mix.
>    Logging functions expect the file and line to be the one
>    where the logging function is placed. When I work with C
>    functions I tend to call them through a template that will
>    check the error return code. See:
>    http://dlang.org/phobos/std_exception.html#.errnoEnforce
>    Such templates pick up file and line numbers from where
>    they are instantiated and pass them on to the exception
>    ctor as runtime values.
>    Now when I use error(), I see no way to pass it runtime
>    file and line variables to make the log file reflect the
>    actual file and line where the error occured, instead of
>    some line in the template or where ever I caught the
>    exception.
>    Not all errors/exceptions are fatal and we might just want
>    to log an exception and continue with execution.

This is a tricky situation.  Log files generally have a specific
format for a given application, and I often don't want APIs I
call writing lines to whatever log I have open.  What I tend to
like the best is for APIs that log data to log to an internal
circular buffer, and provide me the option to request that log
data.  Then if I get an error while using that API and I want
additional context, I can pull the internal logs and examine them
or dump them in my own application's log file.

On Monday, 15 September 2014 at 18:24:07 UTC, Marco Leise wrote:
> Ah, so you avoid recursion issues by separating the calls to
> error() et altera from the actual process of writing to disk
> or sending via the network.
>
> Behind error() there would be a fixed implementation
> controlled by the author of the logging library that just
> appends the payloads to a list.
> Another thread would pick items from that list and push them
> into our Logger classes where we can happily use the logging
> functionalities ourselves, because they would just get
> appended to the list and wait for their time instead of
> causing an immediate recursive call.
>
> So basically your idea is message passing between the
> application and a physical (probably low priority) logging
> thread. This should also satisfy those who don't want to wait
> for the logging calls to finish while serving web requests.
> How do such systems handle a full inbox? In Phobos we have
> http://dlang.org/phobos/std_concurrency.html#.OnCrowding

In MSBuild (where we used a custom but extensible logging system)
we had this exact issue with some of our larger customers who
were logging to remote databases.  Our solution in that case was
to block the caller and force a flush down to a certain backlog
level (we had a limit and hysteresis).  This is not unlike
garbage collector behavior.  In fact, you almost certainly want
to have a configuration of this sort so that users of your
library can help ensure that the logging subsystem does not
starve the rest of the application of memory.

Another alternative (for completeness) is to drop the messages,
but this is almost invariably NOT desirable.

On Monday, 15 September 2014 at 19:16:27 UTC, Cliff wrote:

and you can do all that with std.logger.

again, the idea of std.logger is not to give you everything, because nobody knows what that even is, the idea is to make it possible to do everything and have it understandable later and use transparently

On Monday, 15 September 2014 at 22:33:46 UTC, Robert burner Schadek wrote:
> and you can do all that with std.logger.
>
> again, the idea of std.logger is not to give you everything, because nobody knows what that even is, the idea is to make it possible to do everything and have it understandable later and use transparently

Issues like threading behavior and (a)synchronicity guarantees are part of the API, though, and need to be clarified as part of the std.logger design.

David

On Monday, 15 September 2014 at 22:39:55 UTC, David Nadlinger
wrote:
> On Monday, 15 September 2014 at 22:33:46 UTC, Robert burner Schadek wrote:
>> and you can do all that with std.logger.
>>
>> again, the idea of std.logger is not to give you everything, because nobody knows what that even is, the idea is to make it possible to do everything and have it understandable later and use transparently
>
> Issues like threading behavior and (a)synchronicity guarantees are part of the API, though, and need to be clarified as part of the std.logger design.
>
> David

This is *really* what I am getting at.  Even if not another line
of code is written nor feature added, its important to state what
is actually intended so people know where the limits are a
priori, rather than finding an implicit contract and then running
with it (leaving you with legacy behavior to potentially maintain
later.)

On Monday, 15 September 2014 at 22:39:55 UTC, David Nadlinger wrote:
> Issues like threading behavior and (a)synchronicity guarantees are part of the API, though, and need to be clarified as part of the std.logger design.

the threading behavior has been clarified in the api docs.

the (a)synchronicity guarantees is part of the concrete Logger impl. the Logger api does not force synchronize or asynchronize behavior, it allows both to be implemented by every subclass of Logger.

On Monday, 15 September 2014 at 22:47:57 UTC, Robert burner
Schadek wrote:
> On Monday, 15 September 2014 at 22:39:55 UTC, David Nadlinger wrote:
>> Issues like threading behavior and (a)synchronicity guarantees are part of the API, though, and need to be clarified as part of the std.logger design.
>
> the threading behavior has been clarified in the api docs.
>
> the (a)synchronicity guarantees is part of the concrete Logger impl. the Logger api does not force synchronize or asynchronize behavior, it allows both to be implemented by every subclass of Logger.

Alright.  BTW, thanks for undertaking this project - every app of
reasonable size needs logging and I think having a standard
logging library is just one more of those ecosystem improvements
that gets people up and running quickly.

Please see the review thread for some looooong comment on multi-threading issues with this design.

-- 
Marco