Potential false positive error of "Missing return statement" with Optional[NoReturn] typehint

[jamesbraza]

I am a big fan of mypy, and have learned a ton about static type checking through mypy. I have a suggestion of a potential improvement.

I have what I think is a false positive error when using the type hint Optional[NoReturn]. Please see the below code sample.

from typing import NoReturn, Optional


class MaybeRaiseException:
    """Maybe raise an exception, maybe not."""

    def __init__(self):
        self._should_raise_exception: bool = False

    def potentially_raise_exception(self) -> Optional[NoReturn]:
        # mypy does error
        if self._should_raise_exception:
            raise Exception

    def potentially_raise_exception2(self) -> Optional[NoReturn]:
        # mypy doesn't error
        if self._should_raise_exception:
            raise Exception
        else:
            return None

Running mypy yields:

../path/to/missing_return_noreturn.py: note: In member "potentially_raise_exception" of class "MaybeRaiseException":
../path/to/missing_return_noreturn.py:10: error: Missing return statement  [return]

IMO, using the type hint Optional should not require one to type out return None. It should be implied that None will be returned if no return statement is included.

I think mypy should not report "Missing return statement" in this case. Let me know what you think!

---

Versions

Python==3.8.5
mypy==0.782

[hauntsaninja]

Duplicate of #3974, #9000 and others

[gvanrossum]

Separately, what does Optional[NoReturn] even mean? It may not return??? That seems outside of the intended use case for NoReturn.

[jamesbraza]

I do agree that it's outside of the intended use case. Here's why I used it:

I think a type hint of Optional[NoReturn] succinctly informs developers of the two possible outcomes:

1. Returning None
2. Raising an exception

Also, it informs mypy that the method may return None, as opposed to the default Any. As you say, I think the NoReturn aspect is not properly used as intended by mypy, but I am okay with that. I believe without a type hint in the method signature, mypy wouldn't type check the internals either.

I think that a docstring is probably a superior way of communicating the method's intended behavior, but at least mypy knows half of what the method does.

Feel free to follow up! :)

[hauntsaninja]

You can use the mypy option --check-untyped-defs if you wish mypy to check the internals of an untyped function.

Since basically anything in Python can raise an exception, using -> None already kind of informs developers of that ;-) This would also have the happy side effect of you not having to write return None.

More generally, mypy's type system doesn't support checked exceptions (and is unlikely to do so), although there's some discussion in #1773 and others.