March 11, 2012
Unfortunately, the discussion has ground to a halt again, so consider this a friendly reminder that there is still one day left until the end of the review period.

David
March 11, 2012
On Sun, 11 Mar 2012 16:49:24 -0500, David Nadlinger <see@klickverbot.at> wrote:

> Unfortunately, the discussion has ground to a halt again, so
> consider this a friendly reminder that there is still one day
> left until the end of the review period.
>
> David
>

Has Jose updated anything?
March 11, 2012
On Sunday, 11 March 2012 at 22:09:54 UTC, Robert Jacques wrote:
> Has Jose updated anything?

Not sure what you mean – the latest state of the code is at https://github.com/D-Programming-Language/phobos/pull/432. I was more referring to the design-level discussions anyway, though.

David

March 11, 2012
On 3/11/12 4:49 PM, David Nadlinger wrote:
> Unfortunately, the discussion has ground to a halt again, so consider
> this a friendly reminder that there is still one day left until the end
> of the review period.
>
> David

I thought more about the point made about mixing throwing and logging levels. I agree that it's awkward to e.g. log to critical without throwing etc. I personally think in that case you really want the error log, but hey, point taken.

Here's a suggestion:

* Don't throw from the critical log and don't abort from the fatal log.

* Define the logging functions such that logging an exception will log its toString() and then throw the exception.

* Regarding static import log = std.log, I suggest we keep course.

Works?


Andrei
March 12, 2012
On Sun, Mar 11, 2012 at 05:28:44PM -0500, Andrei Alexandrescu wrote: [...]
> I thought more about the point made about mixing throwing and logging levels. I agree that it's awkward to e.g. log to critical without throwing etc. I personally think in that case you really want the error log, but hey, point taken.
> 
> Here's a suggestion:
> 
> * Don't throw from the critical log and don't abort from the fatal log.
> 
> * Define the logging functions such that logging an exception will log its toString() and then throw the exception.
[...]

+1.

I feel much more comfortable with this design.


T

-- 
Tell me and I forget. Teach me and I remember. Involve me and I understand. -- Benjamin Franklin
March 12, 2012
On Sun, 11 Mar 2012 17:14:37 -0500, David Nadlinger <see@klickverbot.at> wrote:

> On Sunday, 11 March 2012 at 22:09:54 UTC, Robert Jacques wrote:
>> Has Jose updated anything?
>
> Not sure what you mean – the latest state of the code is at
> https://github.com/D-Programming-Language/phobos/pull/432. I was
> more referring to the design-level discussions anyway, though.
>
> David

There was a bunch of discussions/suggestions and then silence from Jose. I assumed he was trying stuff out or thinking about it and would post an update to the newsgroup.
March 12, 2012
On Sun, Mar 11, 2012 at 3:28 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 3/11/12 4:49 PM, David Nadlinger wrote:
>>
>> Unfortunately, the discussion has ground to a halt again, so consider this a friendly reminder that there is still one day left until the end of the review period.
>>
>> David
>
>
> I thought more about the point made about mixing throwing and logging levels. I agree that it's awkward to e.g. log to critical without throwing etc. I personally think in that case you really want the error log, but hey, point taken.
>

I thought about this a lot too and right now I think that if we want to remove asserting from fatal and remove throwing from critical then we should just remove those log levels completely. To me they don't add any additional value. The whole point of having them in the first place was because of their assert and throw semantic.

> Here's a suggestion:
>
> * Don't throw from the critical log and don't abort from the fatal log.
>
> * Define the logging functions such that logging an exception will log its toString() and then throw the exception.
>

This would be great if it made everyone happy but I think it would also confuse developers coming from Java and C#. I think most developer coming from Java and probably C# are used to having:

logger.info(e, "format message", ...);

log the formatted message and the exception e. Ideally what I would like is:

enum Severity { fatal, error, warning, info }; // fatal cannot be disabled // none of the severity levels assert or throw and we have a template: logAndThrow!(FileNotFoundException, Severity.{fatal,error,warning,info})("formatted message", args...);

logAndThrow logs the message, and throws a FileNotFoundException object with a message equal to the "formatted message". Unfortunately to implement this in a consistent way I would have to rethink the way the current "façade" is designed/implemented.

> * Regarding static import log = std.log, I suggest we keep course.
>
> Works?
>

I think there is currently too much disagreement on std.log. I am honestly too busy juggling family, friends, school and work. I am currently leaning towards removing std.log from the review queue and spending some time ironing out the details pointed in this thread. I would like to experiment with some things before making any real suggestions but I would really like to have a logging library that I use throw/assert for me as it would simplify my code.

I would like to thank everyone that commented on the design as it was really helpful for me to understand everyone's point of view and expectations.

Thanks! Thoughts?
-Jose

>
> Andrei
March 12, 2012
On Wed, Mar 7, 2012 at 7:16 AM, Robert Jacques <sandford@jhu.edu> wrote:
> On Tue, 06 Mar 2012 21:22:21 -0600, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 3/6/12 6:05 PM, Geoffrey Biggs wrote:
>>>
>>> That approach means that if I actually do have a fatal error, I can't mark it as such.
>>
>>
>> Use log.fatal for those.
>>
>> Andrei
>
>
> But fatal "Logs a fatal severity message. Fatal log messages terminate the application after the message is persisted. Fatal log message cannot be disable at compile time or at run time." The point is that he want to log a fatal message and then terminate in a custom manner. I don't see a problem with convince functions that log and error and then throw, but not having the option to not throw is an unnecessary limitation.

Okay. Let me say this one last time. If you don't want to assert or throw don't use fatal and critical. I think we are done beating a dead horse. Maybe it is not clear from the documentation but the only reason why fatal and critical exist is because of their assert and throw semantic. This is also the reason why you can't disable them.

I understand that to a person that has not read the documentation is may not be clear to them that fatal("message") asserts and critical("message") throws. Knowing this observation maybe we can remove these severities and make the behavior more obvious by adding the tempalte logAndThrow.

Thanks,
-Jose
March 12, 2012
On Wed, Mar 7, 2012 at 4:21 AM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> On Tue, 06 Mar 2012 19:59:09 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 3/6/12 4:31 PM, Geoffrey Biggs wrote:
>>>
>>> On 07/03/12 09:25, Jonathan M Davis wrote:
>>>>
>>>> On Tuesday, March 06, 2012 13:08:42 Brad Roberts wrote:
>>>>>
>>>>> On Tue, 6 Mar 2012, Jose Armando Garcia wrote:
>>>>>>
>>>>>> Fix now:
>>>>>>
>>>>>> 1. Add thread name attribute to the default logger
>>>>>> 2. Check that the example compile
>>>>>> 3. Come up with a better name for Rich and rich template
>>>>>> 4. Add @safe pure nothrow const to as many methods as possible
>>>>>> 5. Remove check when setting Configuration.logger
>>>>>
>>>>>
>>>>> I still believe pretty strongly that the logger must not affect
>>>>> application flow, ie, not throw or exit the app. From the feed back,
>>>>> I am
>>>>> not alone in thinking that. I don't believe that "well, don't use those
>>>>> log levels" is a workaround if for no other reason that there will be
>>>>> libraries that contain them and that becomes a "dont use those
>>>>> libraries
>>>>> either" response.
>>>>
>>>>
>>>> Agreed. The logging functions should _not_ throw.
>>>
>>>
>>> +1.
>>>
>>> Is std.log a logging library or a complete error management library?
>>>
>>> If it's a logging library, the last thing it should be doing is affecting program flow. In the case of fatal, in particular, the program may need to do something else after logging the fatal error before terminating. You could argue that the program should do that before logging the fatal error, but I don't think that's nice semantics.
>>>
>>> On the other hand, if it's a complete error management library, it probably shouldn't be called std.log.
>>
>>
>> I don't see why the agitation around this particular matter. It's a matter of convenience, much like writeln (as opposed to just write). Let's admit that it often happens that you want to log some troublesome stuff just before throwing an exception with essentially the same message, so the thing is shown on the screen and also persisted in the log. Without a critical level, the pattern would be:
>>
>> string message = stuff() + ": " + moreStuff();
>> log.error(message);
>> throw new Exception(message);
>>
>> It's nice to encapsulate this frequent pattern, hence:
>>
>> log.critical(stuff() + ": " + moreStuff());
>>
>> If you want to log but not throw, use log.error. I don't think the response "dont use those libraries either" is meaningful.
>
>
> I think access to the fatal/critical logging level should not be coupled with throwing exceptions.  I have no problem with having critical or fatal convenience functions that throw and log, but it should not be a *requirement*, and it should not be the default.
>
> I'd combine these two levels into one (there is no semantic difference
> except one throws an exception and one throws an error), and if I got my
> way, log.critical(...) would log a message and logAndThrow!(E =
> Exception)(...) (name to be determined) would log a critical message and
> throw the given exception/error with the same message.
>

Yes, I am leaning toward this idea. Give me some time to come up with a better API that would make this logAndThrow template possible (we need to hint the Logger implementation that it needs to flush).

Thanks,
-Jose

> -Steve
March 12, 2012
On Wed, Mar 7, 2012 at 4:31 AM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> On Tue, 06 Mar 2012 22:54:39 -0500, James Miller <james@aatch.net> wrote:
>
>> Surprisingly, I agree with the idea that fatal and critical shouldn't throw, or at least shouldn't throw by default, maybe a configuration option would allow for that functionality. Logging probably shouldn't affect program flow.
>>
>> Its possible that I may need to log a "critical" error, then do some graceful shutdown.
>
>
> I see this pattern emerging:
>
> try
> {
>   critical("Connection aborted!");
> }
> catch(LoggingException e)
> {
> }
>
> // do graceful shutdown
> ...
>
> throw SomeError("Connection aborted!");
>

Or you can just:

scope(exit) // do graceful shutdown

error("connection aborted");
throw SomeError("connection aborted");

Or better yet:

scope(exit) // do graceful shutdown
//...
logAndThrow!(Exception, Severity.error)("connection aborted");

> -Steve