Voting: std.logger

Marco Leise via Digitalmars-d digitalmars-d at puremagic.com
Tue Aug 26 23:22:15 PDT 2014


Am Wed, 27 Aug 2014 01:09:21 +0000
schrieb "Dicebot" <public at dicebot.lv>:

> On Wednesday, 27 August 2014 at 00:09:15 UTC, Marco Leise wrote:
> > As far as I know, exactly this is not possible with the
> > current GC implementation. The exception you catch there has
> > just been allocated somewhere deeper in the log function. But
> > all GC allocations in a GC invoked dtor cause MemoryErrors and
> > program abortion/crashes. :(
> >
> > In a perfect world I'd imagine you can set up a fallback
> > logger. So if the disk is full an exception is thrown by e.g.
> > std.stdio.File, which is passed as an error level log message
> > to the fallback logger, which might write to stderr:
> > "ERROR: Could not write the following message to logXYZ:
> > <message>
> > The reason was: Disk full"
> 
> I don't think it will help either. The very moment exception is 
> allocated inside std.stdio.File your program will crash, it won't 
> get to fallback. Only solution is to implement your logger as 
> @nothrow thing by using only C functions internally instead of 
> std.stdio - something that feels overly limited for a general use 
> case.

Exactly, I just needed someone else to speak it out. :)

> I really think this is the case where you should roll your 
> own FileNoThrowingLogger and go with it.

*Me* or everyone who needs to log something in a dtor?

> In a long term this is something much better to be fixed in GC 
> implementation than constantly hacked in stdlib modules.

Or is this maybe the other language change (besides not
generating code for unused lambdas) that should be pushed
with std.log, because otherwise it will never be solved ?

I don't know, but no logging in dtors is a serious
and hard to sell limitation. Not the author's fault though.

-- 
Marco



More information about the Digitalmars-d mailing list