CODEWITHSUNDEEP
pythonpython-typing
Yuval Pruss
Yuval Pruss

Reputation: 9856

Python type hinting with exceptions

I have a function that looks like this:

def check_for_errors(result):
    if 'success' in result:
        return True

    if 'error' in result:
        raise TypeError

    return False

In successful run of this function, I should get a bool, but if there is an error I should get a TypeError- which is OK because I deal with it in another function.

My function first line looks like this:

def check_for_errors(result: str) -> bool:

My question is: Should I mention the error in my type hinting?

Upvotes: 123

Views: 74693

Answers (4)

Matvey
Matvey

Reputation: 31

You can use NoReturn: https://peps.python.org/pep-0484/#the-noreturn-type

from typing import NoReturn

def stop() -> NoReturn:
    raise RuntimeError('no way')

Or this:

from typing_extensions import NoReturn

def stop() -> NoReturn:
    raise RuntimeError('no way')

Upvotes: 3

Jonathan Herrera
Jonathan Herrera

Reputation: 6184

There are good reasons for making the exception path part of the type annotations of your function, at least in certain scenarios. It just provides you more help from the type checker whenever you need to understand which exceptions the caller has to handle. (If you are interested in a more in-depth analysis, I wrote a blog post about this.)

As it is out of scope of the Python typing system to indicate which exceptions a function raises (like, for instance, in Java), we need a workaround to get this. Instead of raising, we can return the exception. That way, the exception becomes part of the function signature, and the caller has to handle it, leveraging the power of the type checker.

The following code is inspired by the way exception handling is done in Rust: It provides a Result type which can either be Ok or Err. Both Ok and Err classes have an unwrap() function, which either returns the wrapped value or raises the wrapped exception.

from typing import Generic, TypeVar, NoReturn


OkType = TypeVar("OkType")
ErrType = TypeVar("ErrType", bound=Exception)


class Ok(Generic[OkType]):
    def __init__(self, value: OkType) -> None:
        self._value = value

    def unwrap(self) -> OkType:
        return self._value


class Err(Generic[ErrType]):
    def __init__(self, exception: ErrType) -> None:
        self._exception = exception

    def unwrap(self) -> NoReturn:
        raise self._exception


Result = Ok[OkType] | Err[ErrType]

Result is a Generic, and it takes two types: the type of the Ok value, and the type of the Err exception. Here it is applied to your example:

def check_for_errors(result: list[str]) -> Result[bool, TypeError]:
    if 'success' in result:
        return Ok(True)

    if 'error' in result:
        return Err(TypeError())

    return Ok(False)


def careful_method(result: list[str]):
    r = check_for_errors(result)  
    # Now, typechecker knows that r is `Result[bool, TypeError]`
    if isinstance(r, Err):
         # implement the error handling
    else:
         # implement the happy path

# If you do not want to handle the exception at this stage 
def careless_method(result: list[str]):
    check_for_errors(result).unwrap()

This is just a rough code sketch to demonstrate the principle. There is actually a more sophisticated library, poltergeist which I would recommend to use, if you consider following this approach.

Upvotes: 22

Martijn Pieters
Martijn Pieters

Reputation: 1124040

Type hinting can't say anything about exceptions. They are entirely out of scope for the feature. You can still document the exception in the docstring however.

From PEP 484 -- Type Hints:

Exceptions

No syntax for listing explicitly raised exceptions is proposed. Currently the only known use case for this feature is documentational, in which case the recommendation is to put this information in a docstring.

Guido van Rossum has strongly opposed adding exceptions to the type hinting spec, as he doesn't want to end up in a situation where exceptions need to be checked (handled in calling code) or declared explicitly at each level.

Upvotes: 156

Jim Wright
Jim Wright

Reputation: 6058

It is usually a good idea to document the error. This means that another developer using your function will be able to handle your errors without having to read through your code.

Upvotes: 11

Related Questions