any logger in core?

David House dhouse at janestreet.com
Tue Nov 13 09:34:03 GMT 2012


Also, there is a function for logging fatal errors. It's called failwith :)

On Tue, Nov 13, 2012 at 9:27 AM, Malcolm Matalka <mmatalka at gmail.com> wrote:
> I agree with David.  The current logger I am using at work as 5 or 6 log
> levels and I have found little value in it.  I think 'fatal' is
> especially devilish since, in such a situation, your monitoring tools
> should be the ones determining that.
>
> /M
>
> David House <dhouse at janestreet.com> writes:
>
>> 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? 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.
>>
>> Putting it another way: three logging levels should be enough for anyone! :)
>>
>> On Tue, Nov 13, 2012 at 8:02 AM, Francois Berenger
>> <francois.berenger.working at gmail.com> 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.)



More information about the core mailing list