3 ms·

The author argues that the error level should not exist because according to him, an error can either be handled or bubble up and logging an error is in a way h

The author argues that the error level should not exist because according to him, an error can either be handled or bubble up and logging an error is in a way handling it. If an error is handled, it is not an error anymore. I think he is overthinking it a bit. Yes there should be very little places where an error is actually logged, yet is does not mean that it should not exist. In web applications you very often have one instance of: try: return handle_request() except Exception: logger.exception('Something bad happened') return 500 Sure you can argue that as the client received a 500 it is not an error anymore, but this doesn't help you notice and fix the problem.

sagichmal 8y ago
Any exception that bubbles all the way up to a request-scoped catch block indicates a bug in your handler logic. It should probably crash your program, or at least be reported as a structured event to your exception tracking system. In either case, logger.Info is sufficient to record this event in the application logs.
- nicolaslem 8y ago
  Why should exception tracking and logging be two separated things? They perform the same job, an exception tracking system is just another way to present log records. The real problem is that people still associate logs with lines of text in a file, whereas most logging frameworks create full objects containing a ton of information[0]. Once you stop considering logs as text, exception tracking and logging really become the same thing. [0] https://docs.python.org/3/library/logging.html#logrecord-attributes https://docs.python.org/3/library/logging.html#logrecord-att...
  - Rapzid 8y ago
    Exactly. As a subset of monitoring, it can probably be thought of as eventing; like all monitoring. What's a metric? A measurement event. Etc. Perhaps a name change is in order; Event Tracing for Windows anyone? Eventing.. Event Tracing. IDK.
  - sagichmal 8y ago
    Conceptually they are very similar, in the same way that metric data and log data are also very similar. But we don't have good technological solutions to support muxing all streams of observability data together and dealing with them efficiently, either in transport or in storage/query. Good program architecture in 2018 demands some degree of compromise. In my experience it's best to separate console logging (as in this article) from structured logging, from metrics, from distributed tracing, from exception tracking.

sagichmal 8y ago

Any exception that bubbles all the way up to a request-scoped catch block indicates a bug in your handler logic. It should probably crash your program, or at least be reported as a structured event to your exception tracking system. In either case, logger.Info is sufficient to record this event in the application logs.

nicolaslem 8y ago
Why should exception tracking and logging be two separated things? They perform the same job, an exception tracking system is just another way to present log records. The real problem is that people still associate logs with lines of text in a file, whereas most logging frameworks create full objects containing a ton of information[0]. Once you stop considering logs as text, exception tracking and logging really become the same thing. [0] https://docs.python.org/3/library/logging.html#logrecord-attributes https://docs.python.org/3/library/logging.html#logrecord-att...
- Rapzid 8y ago
  Exactly. As a subset of monitoring, it can probably be thought of as eventing; like all monitoring. What's a metric? A measurement event. Etc. Perhaps a name change is in order; Event Tracing for Windows anyone? Eventing.. Event Tracing. IDK.
- sagichmal 8y ago
  Conceptually they are very similar, in the same way that metric data and log data are also very similar. But we don't have good technological solutions to support muxing all streams of observability data together and dealing with them efficiently, either in transport or in storage/query. Good program architecture in 2018 demands some degree of compromise. In my experience it's best to separate console logging (as in this article) from structured logging, from metrics, from distributed tracing, from exception tracking.