What does logging.exception() record that logging.error() alone does not?

## The one-line identity `Logger.exception(msg, *args)` is a convenience wrapper. Its entire behaviour is: log at `ERROR` level with `exc_info=True`. Nothing else. Writing `log.exception("sync failed")` and `log.error("sync failed", exc_info=True)` produces byte-identical output. The method exists because logging a caught exception without its traceback is the single most common logging mistake, and a dedicated verb makes the right thing shorter than the wrong thing. ## What `exc_info` actually resolves to When `exc_info` is truthy, the logging machinery captures the *currently handled* exception — the same thing `sys.exc_info()` returns — and stores the `(type, value, traceback)` triple on the log record. A formatter later renders it as the familiar `Traceback (most recent call last): ...` block underneath the message. "Currently handled" is the crucial qualifier. Inside an `except` block there is one; outside, there is not. Call `log.exception("oops")` at module level and you get the message followed by the literal line `NoneType: None` — a puzzling artefact that always means *you logged a traceback where no exception was live*. The same applies after the `except` block has finished: Python clears the exception state on the way out, so a deferred `log.exception()` records nothing useful. `exc_info` is not limited to `True`. It also accepts: - an **exception instance** — `log.error("deferred", exc_info=exc)`, useful when you stashed the exception and log it later, or when you are reporting an exception you never caught in this frame (one pulled off a queue, or a `Future`'s stored exception); - an explicit **`(type, value, traceback)` tuple** — what a top-level hook such as `sys.excepthook` is handed. Because `exc_info` is an ordinary keyword on every level method, the traceback is not welded to ERROR. A retriable failure that you intend to swallow is honestly a `WARNING` *with* a traceback; a failure that is about to kill the process is `CRITICAL` with one. `logging.exception()` is only the ERROR-level shorthand, and reaching for it purely to get the traceback is how logs end up full of ERROR entries for things that were handled fine. ## `stack_info` is a different question `stack_info=True` is often confused with `exc_info` because both append a multi-line block. They answer different questions: - `exc_info` → *where did the exception come from?* It renders the traceback of a raised exception, unwinding from the `raise` site. - `stack_info` → *how did control reach this logging call?* It renders the current call stack, headed `Stack (most recent call last):`, whether or not an exception exists. `stack_info` earns its keep on the puzzling non-exceptional log line: a warning that fires from a helper called in a dozen places, a deprecation notice, a "cache miss" you cannot attribute. It costs a stack walk plus formatting per call, so it belongs on rare lines, not on a hot path. ## Why not just format the traceback yourself `traceback.format_exc()` returns the same text as a string, and `log.error("failed: " + traceback.format_exc())` looks equivalent. It is worse in three ways. The traceback becomes part of the message string, so structured handlers cannot separate it; anything that filters, redacts or ships records field-by-field sees one opaque blob. Downstream formatters lose the ability to decide whether to render it at all. And, called outside a handler, `format_exc()` quietly yields the string `"NoneType: None"` and concatenates it into your message rather than being visibly absent. Let logging carry the exception as data and let the handler decide how to render it. ## Writing the message The traceback already tells you the exception type, its message and the code path. It does not know which of 6,800 rows you were on, which remote host you called, or which tenant the request belonged to. So the message should carry the *identifying* context and not restate the exception: `log.exception("inventory sync failed for batch %s at row %d", batch_id, offset)` beats `log.exception("got a TimeoutError")`. Use `%`-style placeholders with arguments rather than an f-string so the record keeps the parameters separately and the formatting cost is skipped when the level is disabled. ## The decision it implies Calling `log.exception()` is a claim: *this failure stops here, and this record is its report.* If you are going to re-raise, the exception is still travelling with its traceback intact and something above you will report it — logging here just doubles the report. That is the boundary rule this leaf is really about, and `logging.exception()` is the tool you use exactly once, at the layer that actually stops the failure.