Create a Custom Python Exception for Validation

Select a timestamp to watch that moment on YouTube.

1. 00:00

   Validation is not complete just because a string can be converted to an integer. Our order example requires one or more units. The text "two" cannot be converted, while the text "0" converts perfectly and still violates the business rule. If we write only return int(text), those inputs follow two inconsistent paths: a raw ValueError for the word, and a successful zero for the invalid quantity. We will build a small domain exception called QuantityError, translate the expected conversion failure without losing its cause, and apply the positive-quantity check after conversion. The goal is not to invent an exception for every function.

2. 00:42

   A specific type is useful when a caller needs to respond to one domain failure while leaving unrelated programming bugs visible. In the companion browser lesson, you can repair the starter function and run a checker that inspects both the returned values and the exception path. Three is valid. Zero is not valid under this order rule, yet it returns as an ordinary result. The word "two" raises ValueError because int cannot parse it. The raw error type does not tell the caller that the problem concerns a quantity field, and the zero case does not raise anything at all. We need to separate two checks.

3. 01:22

   First, is the text a decimal integer? Second, does that integer satisfy the one-or-more-units rule? A broad except around the whole function would be the wrong shortcut. It could catch a bug in unrelated code and report it as a quantity mistake. We should catch only the conversion error we expect and add an explicit rule afterward. The custom exception can inherit from ValueError so generic error handling still recognizes it as a bad value, while quantity-specific handling can catch it directly. The outer exception is now QuantityError, a subclass of ValueError. Its message names the invalid units rather than leaving the caller to infer the field from a generic conversion message.

4. 02:08

   The original ValueError remains in __cause__ because the raise statement used from exc. If this error were unhandled, Python would show both exceptions in the traceback and say that the first was the direct cause of the second. We are not hiding the lower-level explanation; we are adding context at the boundary where the text becomes a domain quantity. Notice that a converted zero has no conversion exception to chain. It will need a direct QuantityError after the int call. That distinction makes the code easier to reason about and test. The caller can catch QuantityError to ask for a corrected number while a NameError or unexpected TypeError still surfaces as a separate problem.

5. 02:52

   Conversion is isolated in the try block. Only its ValueError is translated, so a programming mistake elsewhere is not silently renamed. After conversion, the second if statement checks the rule that a quantity must be positive. Zero and negative values raise QuantityError directly, with the offending input in the message. A valid value returns as an integer. In the website task, the starter code only converts, so both failure paths need your attention. Use a small subclass rather than storing extra fields unless your caller actually needs them. The subclass adds a stable type, while the message adds useful human context.

6. 03:34

   The exact message wording is a design choice; the checker only requires that the offending text be included. For text that cannot be converted, it also verifies that the original ValueError is preserved as the cause. A downstream caller could inspect __cause__ when logging a detailed diagnostic, while showing only the concise QuantityError message to the person entering an order. Those two audiences need different levels of detail. Keeping both exceptions available avoids choosing between a readable interface and a useful debugging trail. This encourages a correction that stays transparent during debugging.

7. 04:15

   The first assertion shows that a valid multi-digit value can include surrounding whitespace and still convert to twelve. The loop probes zero and a negative value, two cases that conversion alone would accept. The final branch checks nonnumeric text and inspects the cause, so a solution that merely replaces the error message without chaining will not pass. These checks describe the function's contract better than a single successful print. Imagine a command-line inventory tool calling parse_units. It might catch QuantityError, show the specific message, and ask the person to enter the quantity again. A different error, such as an undefined variable in the reservation code, should still stop the program or reach its normal error reporter.

8. 05:03

   A bare except would confuse those two situations and could make a damaged order look like bad input. The custom type creates a deliberate boundary between expected correction and a software defect. In a real system, you might also decide whether whitespace-only text, very large quantities, or signs such as plus should be accepted. Those are domain decisions, not properties a custom exception can determine for you. State the rule, validate it at the boundary, and keep unexpected bugs separate from expected bad input. Then run the companion task and quiz. If a different module calls parse_units, it can handle QuantityError intentionally while still retaining the original conversion failure for diagnostics when necessary.