# The Exception Handler

> Good code handles failure as gracefully as success.

Canonical URL: <https://datadriven.io/problems/the_exception_handler>

Domain: Python · Difficulty: medium · Seniority: L3

## Problem

Given a list of [numerator, denominator] operations, for each return: numerator / denominator as float on success; 'division by zero' when denominator is 0; 'invalid input' when either operand is not numeric. Return the results as a list.

## Worked solution and explanation

### Why this problem exists in real interviews

This tests **structured exception handling** with multiple error types. It probes whether a candidate can catch specific exceptions, produce meaningful error messages, and process a batch of operations without letting one failure stop the rest.

---

### Break down the requirements

#### Step 1: Iterate through each operation

Each operation has a numerator and denominator.

#### Step 2: Attempt the division with try/except

Catch `ZeroDivisionError` and `TypeError` (for non-numeric inputs) separately.

#### Step 3: Return results or error messages

Build a list with either the numeric result or a descriptive error string for each operation.

---

### The solution

**Batch division with typed exception handling**

```python
def safe_divide(operations: list) -> list:
    results = []
    for op in operations:
        try:
            result = op['numerator'] / op['denominator']
            results.append(result)
        except ZeroDivisionError:
            results.append('division by zero')
        except TypeError:
            results.append('non-numeric input')
    return results
```

> **Time and Space Complexity**
>
> **Time:** O(n) where n is the number of operations.
> 
> **Space:** O(n) for the results list.

> **Interviewers Watch For**
>
> Whether you catch specific exceptions rather than a bare `except`. Catching `Exception` or using bare `except` masks bugs and is a code smell in production.

> **Common Pitfall**
>
> Catching `ValueError` instead of `TypeError`. Non-numeric inputs like strings cause `TypeError` during division, not `ValueError`.

---

## Common follow-up questions

- What if you also needed to handle integer overflow? _(Tests awareness that Python has arbitrary-precision integers, so overflow does not occur natively.)_
- How would you log the errors for debugging? _(Tests structured logging with the exception traceback.)_
- What if operations should stop on first error? _(Tests early return vs batch processing design decisions.)_

## Related

- [All practice problems](https://datadriven.io/problems)
- [Mock interview mode](https://datadriven.io/interview/the_exception_handler)
- [Python Interview Questions](https://datadriven.io/python-interview-questions)
- [Data Engineering Interview Prep Guide](https://datadriven.io/data-engineer-interview-prep)
- [Daily Challenge](https://datadriven.io/daily)

---

Source: DataDriven (https://datadriven.io). 100% free data engineering interview prep. Live code execution against Postgres 16, Python 3.11, and Spark sandboxes. No paywall, no premium tier, no signup gate.