Error Handling Internals

Preview — 3 of 10 questions

What is the output of the following code?

javascript

import sys

def log_current_exception():
    exc_type, exc_value, exc_tb = sys.exc_info()
    print(exc_type.__name__)
    print(exc_value)

try:
    raise ValueError("boom")
except ValueError:
    log_current_exception()

ATypeError: exc_info() takes no arguments

BNone then None

CValueError then boom

D<class 'type'> then <class 'BaseException'>

What is the output of the following code?

javascript

from contextlib import ContextDecorator

class Timed(ContextDecorator):
    def __enter__(self):
        print("start")
        return self

    def __exit__(self, *args):
        print("end")
        return False

@Timed()
def do_work():
    print("working")

do_work()

ATypeError: 'Timed' object is not callable

Bstart, working, end

Cstart, end, working

Dworking, start, end

Which statement correctly describes what happens when a generator with a try/finally block is abandoned (goes out of scope) without being fully exhausted or explicitly .close()d?

AWhen the generator object is eventually garbage-collected, Python automatically throws a GeneratorExit exception into it at its current suspension point, which triggers any pending finally block to run — the same mechanism as calling .close() explicitly, just triggered by garbage collection instead.

Bfinally blocks inside generators behave completely differently from finally blocks in regular functions and are never guaranteed to run.

CPython raises an immediate RuntimeError the moment a generator with a pending finally block goes out of scope.

DAn abandoned, unclosed generator's finally block never runs at all, under any circumstances, leaking any resources it was managing.

Answer all 10 questions (7 more), see explanations for every answer, and track your score.