Print Full Python Exception Tracebacks Without Exiting

You will learn how Python exception handling changes traceback output, how to print the active exception's full traceback with the traceback module, and how to log failures while safely continuing with later work.

When an exception is unhandled, Python prints a traceback and terminates the current program flow. A traceback shows:

• the sequence of function calls that led to the failure,
• the source file and line number at each call,
• the line of code that failed, when available,
• the exception type and message.

Once an except block catches the exception, it is no longer unhandled. Python therefore does not automatically display its traceback. The exception information is still available inside that except block, and the standard-library traceback module can format or print it.

Use traceback.print_exc() inside an except block to print the traceback for the exception currently being handled:

import traceback

try:
    do_stuff()
except Exception:
    traceback.print_exc()
    # Execution continues after this block.

traceback.print_exc() writes to standard error (sys.stderr) by default, like Python's usual exception display. Catching Exception is usually appropriate for application errors. It intentionally does not catch control-flow exceptions such as KeyboardInterrupt and SystemExit.

Think of a traceback as a route history for a delivery that failed.

• Each function call is a stop on the route.
• The exception is the delivery problem.
• An unhandled exception makes Python automatically print the route history and stop the delivery service.
• A try/except block is a support desk that intercepts the problem.

After intercepting it, the support desk must explicitly ask for the route history with traceback.print_exc(). It can then record the problem and let the rest of the service continue.

Import Python's built-in traceback module and call print_exc() from within except.

import traceback

def divide(total, count):
    return total / count

try:
    result = divide(10, 0)
    print(result)
except Exception:
    traceback.print_exc()

print("The program is still running.")

Typical output includes the call stack and the final error:

Traceback (most recent call last):
  File "example.py", line 7, in <module>
    result = divide(10, 0)
             ^^^^^^^^^^^^^
  File "example.py", line 4, in divide
    return total / count
           ~~~~~~^~~~~~~
ZeroDivisionError: division by zero
The program is still running.

If you also need the exception object for a custom message, keep as err:

import traceback

try:
    do_stuff()
except Exception as err:
    print(f"Task failed: {err}")
    traceback.print_exc()

Avoid . is the base exception , not necessarily the type that was raised. Use if you only need the actual type name:

Consider this program:

import traceback

def load_port(value):
    return int(value)

def start_server():
    port = load_port("not-a-number")
    print(f"Starting on port {port}")

try:
    start_server()
except Exception as err:
    print(f"Could not start server: {err}")
    traceback.print_exc()

print("Performing other startup tasks.")

Execution proceeds as follows:

1. Python enters the try block and calls start_server().
2. start_server() calls load_port("not-a-number").
3. int("not-a-number") raises ValueError.
4. Python leaves load_port() and start_server() while looking for a matching handler.
5. The except Exception as err block matches the and stores it in .

Full tracebacks are useful whenever an application can recover from one failed unit of work.

• Batch import jobs: Log the traceback for one malformed CSV row, skip it, and continue importing later rows.
• Background workers: Record why one queued task failed without stopping the worker process.
• Web applications: Log a detailed traceback on the server, then return a safe error response to the client.
• Scheduled scripts: Continue processing other reports or accounts after one API request fails.
• Command-line tools: Report a failed optional operation while still completing independent operations.
• Plugin systems: Prevent one third-party plugin failure from crashing the host application.

In production, send tracebacks to logs rather than exposing them to end users. A traceback can contain internal file paths, implementation details, and sometimes sensitive data included in error messages.

In real projects, developers typically use the logging module rather than direct print() calls. logger.exception() is designed for this: when called inside an except block, it logs a message plus the current exception traceback.

import logging

logging.basicConfig(level=logging.ERROR)
logger = logging.getLogger(__name__)

try:
    do_stuff()
except Exception:
    logger.exception("do_stuff failed; continuing with the next task")

For batch work, handle exceptions at the boundary of each independent item:

import logging

logger = logging.getLogger(__name__)

for filename in filenames:
    try:
        process_file(filename)
    except Exception:
        logger.exception("Could not process %s", filename)
        continue

This approach lets one bad file fail while subsequent files are still processed.

A good recovery handler does more than print an error. It should decide what happens next: skip an item, use a fallback value, retry a temporary operation, or stop cleanly if continuing would create incorrect results. Do not continue merely because it is possible; continue only when the program remains in a valid state.

Printing only the exception message

try:
    do_stuff()
except Exception as err:
    print(err)

This prints a message such as division by zero, but not the path of calls that caused it. Use traceback.print_exc() or logger.exception() as well.

Printing Exception instead of the raised type

except Exception as err:
    print(Exception, err)

Exception is the base class, so this does not tell you whether the actual error was ValueError, KeyError, or another subtype.

except Exception as err:
    print(type(err).__name__, err)

For debugging, the full traceback is usually more useful.

Calling traceback.print_exc() outside except

import traceback

try:
    do_stuff()
except Exception:
    traceback.print_exc()  # Prints active traceback to stderr.

# Include a custom message and the traceback.
try:
    do_stuff()
except Exception as err:
    print(f"Failed: {err}")
    traceback.print_exc()

# Production-style logging.
import logging

logger = logging.getLogger(__name__)

try:
    do_stuff()
except Exception:
    logger.exception("do_stuff failed")

# Get the traceback as text instead of printing it.
try:
    do_stuff()
except Exception:
    text = traceback.format_exc()

Key rules:

• Call print_exc(), format_exc(), or logger.exception() inside except.
• Prefer except Exception: over .

How do I print a full traceback in a Python except block?

Import traceback and call traceback.print_exc() inside the except block.

except Exception:
    traceback.print_exc()

Does traceback.print_exc() stop the Python program?

No. It only prints the traceback of the exception currently being handled. Execution continues after the except block unless you use raise, return, break, or another control-flow statement.

Why does print(err) not show the traceback?

err contains the exception object, whose string form usually includes only its message. The traceback is separate call-stack information managed by Python's exception machinery.

How can I log an exception and its traceback in Python?

Use logger.exception() inside an except block.

• try, except, else, and finally — The complete structure for handling errors, running success-only code, and performing cleanup.
• Python exception hierarchy — Explains why Exception is usually safer to catch than BaseException.
• The logging module — Provides log levels, timestamps, files, and structured production error reporting.
• Raising and re-raising exceptions — Useful when an error should be logged at one layer and handled at another.
• Custom exceptions — Lets applications represent expected domain-specific failure cases clearly.
• Context managers and with statements — Ensure files, locks, and other resources are cleaned up even when exceptions occur.
• Error recovery and retries — Helps decide whether continuing after an exception is safe and how to handle transient failures.