3 ms·

We log extensively. Here are some of my thoughts it - at least in C++, the requirement to be able to log from pretty much anywhere can lead to messy code that

We log extensively. Here are some of my thoughts it - at least in C++, the requirement to be able to log from pretty much anywhere can lead to messy code that either passes a reference to your logger to all classes that might possibly need it, or you've got an extern global somewhere. Yuck. - logging can enable laziness. Being able to log that something weird happened can be considered a sufficient substitute for proper testing. - logs are only as useful as the info they contain. This can mean state needs to be passed around all over the place just so that it can all be eventually logged on one line (it saves your data team from having to do a 'join') - if your logger doesn't support cycling log files it's useless. If something goes wrong you can easily fill a disk.

viraptor 6y ago
I'd disagree with 2 and 4. 2. Given a large enough system you will encounter situations where the only action you can take is to log "this really shouldn't happen" and try to roll back as cleanly as possible. This may be due to either complexity or a bug manifesting in a layer completely different than where it occurred (I've seen a null reference crash on "if(foo) foo->bar();" in the past) 4. I believe loggers should ideally know as little as possible about your logs. Logs can be rotated externally, can be buffered and sent to other hosts without touching the disk, can be ignored. Ideall, the system should care, not the app.
- mmkos 6y ago
  > I've seen a null reference crash on "if(foo) foo->bar();" in the past References can't be null. Regardless, that's a valid check for a null pointer and I don't think what you wrote is at all possible (unless maybe in some multithreaded scenario?).
bradstewart 6y ago
Expanding on your second point, logging is also not a substitute for proper error handling.
gnufx 6y ago
> the requirement to be able to log from pretty much anywhere can lead to messy code Ah, Milewski's example of insight from the supposedly useless mathematical stuff: https://bartoszmilewski.com/2014/12/23/kleisli-categories/ https://bartoszmilewski.com/2014/12/23/kleisli-categories/ (and the corresponding lecture video).
sagichmal 6y ago
> if your logger doesn't support cycling log files it's useless. If something goes wrong you can easily fill a disk. Few applications should be logging to disk directly. Services running under systemd or any modern orchestration platform should log to stdout/stderr and let the system manage the stream.

viraptor 6y ago

I'd disagree with 2 and 4. 2. Given a large enough system you will encounter situations where the only action you can take is to log "this really shouldn't happen" and try to roll back as cleanly as possible. This may be due to either complexity or a bug manifesting in a layer completely different than where it occurred (I've seen a null reference crash on "if(foo) foo->bar();" in the past) 4. I believe loggers should ideally know as little as possible about your logs. Logs can be rotated externally, can be buffered and sent to other hosts without touching the disk, can be ignored. Ideall, the system should care, not the app.

mmkos 6y ago
> I've seen a null reference crash on "if(foo) foo->bar();" in the past References can't be null. Regardless, that's a valid check for a null pointer and I don't think what you wrote is at all possible (unless maybe in some multithreaded scenario?).

bradstewart 6y ago

Expanding on your second point, logging is also not a substitute for proper error handling.

gnufx 6y ago

> the requirement to be able to log from pretty much anywhere can lead to messy code Ah, Milewski's example of insight from the supposedly useless mathematical stuff: https://bartoszmilewski.com/2014/12/23/kleisli-categories/ https://bartoszmilewski.com/2014/12/23/kleisli-categories/ (and the corresponding lecture video).

sagichmal 6y ago

> if your logger doesn't support cycling log files it's useless. If something goes wrong you can easily fill a disk. Few applications should be logging to disk directly. Services running under systemd or any modern orchestration platform should log to stdout/stderr and let the system manage the stream.