3 ms·

> When you write modular code that minimizes assumptions about its context, that situation is a common occurrence. so your code isn't modular after all, becau

by chii 3y ago

> When you write modular code that minimizes assumptions about its context, that situation is a common occurrence. so your code isn't modular after all, because the code is _doing_ logging as a side-effect of the actual functionality. The modularity of your code should mean that the outcome of the functionality is packaged into a bundle of data, and this bundle includes information about errors (or warnings) - aka, a status result. The caller of this module will inspect this data, and they themselves will decide to log (or, if they are a module of their own, pass the data up again). This goes on, until the data goes into a logging layer - solely responsible for logging perhaps.

TeMPOraL 3y ago
Yes, except the problem here is that if the app crashes, you'll lose all the messages in the bundle. That's why people tend to use side-effect logging that persists messages immediately. That, and because it keeps timestamps correct. I suppose this approach would make most sense in event-driven apps where no particular processing takes any meaningful amount of time, so you're constantly revisiting the top-level loop, where the "logging layer" could live. However, most software isn't written this way.
- Too 3y ago
  App segfaulting before having chance to log is mostly a thing in the past, unless you are writing c++. Any other language will instead have a top level exception handler. If you were to take hard crashes into account, you would even have to log before each operation instead of after, basically reverting to printf-debugging.
  - TeMPOraL 3y ago
    > unless you are writing c++ Guilty as charged. > If you were to take hard crashes into account, you would even have to log before each operation instead of after Yes, that's exactly what I see done and do for large enough operations (substeps of those operations only log when they're done). > basically reverting to printf-debugging That's what logging is, fundamentally. printf debugging, but with your own printf that has a few more knobs.

by chii 3y ago

TeMPOraL 3y ago

Yes, except the problem here is that if the app crashes, you'll lose all the messages in the bundle. That's why people tend to use side-effect logging that persists messages immediately. That, and because it keeps timestamps correct. I suppose this approach would make most sense in event-driven apps where no particular processing takes any meaningful amount of time, so you're constantly revisiting the top-level loop, where the "logging layer" could live. However, most software isn't written this way.

Too 3y ago
App segfaulting before having chance to log is mostly a thing in the past, unless you are writing c++. Any other language will instead have a top level exception handler. If you were to take hard crashes into account, you would even have to log before each operation instead of after, basically reverting to printf-debugging.
- TeMPOraL 3y ago
  > unless you are writing c++ Guilty as charged. > If you were to take hard crashes into account, you would even have to log before each operation instead of after Yes, that's exactly what I see done and do for large enough operations (substeps of those operations only log when they're done). > basically reverting to printf-debugging That's what logging is, fundamentally. printf debugging, but with your own printf that has a few more knobs.