any logger in core?
Francois Berenger
francois.berenger.working at gmail.com
Wed Nov 14 01:44:35 GMT 2012
On Tuesday, November 13, 2012 5:43:01 PM UTC+9, David House wrote:
>
> Hmm, I am surprised you want so many!
>
> I claim there is a cost in allowing tons and tons of different log
> levels. Firstly, it complicates the interface. Secondly, it leads to
> different applications choosing different logging levels for
> essentially the same errors. E.g. how do you choose whether some
> particular failure is an error, or a fatal?
After a fatal error, the program cannot continue anymore.
Think about a "fatal injury".
I see a grey zone between warn and error, but I think
programmers are usually smart and can be trusted.
Isn't it likely that
> someone else will make a different choice? There are lines that you
> can draw, but it's a big grey area. Having fewer choices means that
> everyone's programs are more consistent with respect to each other.
>
I agree it's a grey zone.
But the current choice is drastic.
>
> Putting it another way: three logging levels should be enough for anyone!
> :)
>
> On Tue, Nov 13, 2012 at 8:02 AM, Francois Berenger
> <francois.ber... at gmail.com <javascript:>> wrote:
> > The choice in log levels is a little scarce.
> >
> > Currently:
> > raw (I don't know it's level, I guess it's always printed but I may be
> > wrong)
> > then, ordered by my intuitive notion of log priority:
> > debug < info < error
> >
> > I'm used to:
> > debug < info < warn < error < fatal
> >
> > So, I miss the warning and fatal log levels.
> > But, that's just based on my experience.
> >
> > Regards,
> > F.
> >
> >
> > On Thursday, November 8, 2012 7:13:25 PM UTC+9, David House wrote:
> >>
> >> On Thu, Nov 8, 2012 at 3:48 AM, Francois
> >> <francois.b... at gmail.com> wrote:
> >> > I don't know where to find never_returns.
> >>
> >> It's there if you open Core.Std.
> >>
> >> > But the following did work (and never stop):
> >>
> >> You need to explicitly shut down async using the shutdown function in
> >> Async.Std.
> >>
> >> > I'm affraid of open directives, I try to keep my code _very_ explicit
> >> > about what it is doing and which function from which module is used
> >> > (maybe because of past overexposure to some C++ code).
> >>
> >> I think that's exactly the right approach -- I often find myself
> >> making similar comments when doing code review at work. Things are
> >> much easier to follow if opens are reduced, or made more local, and
> >> more explicit.
> >>
> >> That being said, I do allow myself the luxury of opening Core.Std and
> >> Async.Std in most of my modules that use core / async. I find this to
> >> strike a good balance between concision and explicitness.
> >>
> >> One of the reasons is that there are very few *values* brought into
> >> scope by opening Core.Std and Async.Std. This conversation has contain
> >> disproportionally many: never_returns, shutdown, etc. -- an unlucky
> >> coincidence! But nearly everything is squirreled away inside a module,
> >> which helps a lot. (In other words, our "Pervasives" is much smaller
> >> than the ocaml standard library's.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/core/attachments/20121113/ccb7ae2d/attachment-0001.html>
More information about the core
mailing list