Hacker News Reader

Comment by dragonwriter | Hacker News Reader

> If a function can realistically raise a "KeyError" the program should be properly written to accept this at some level

By definition, it is, because there is defined behavior for unhandled exceptions.

If you want to—and this is a valid preference—wrap all exceptions thrown at a lower level and present an API where they are part of the return type that must be addressed by code to pass typechecking, then you do that and return actual values of an appropriate type (you can still use exception types, if you wish) instead of raising exceptions.

Exceptions which you force client code to handle to typecheck are not exceptions, they are return values and should be converted to explicitly that, rather than adding checked exceptions.

View on HN

I think that this is a hard problem and you're right that spamming KeyError everywhere is against the exceptionality of exceptions. But the current completely unchecked model is also misleading. I don't have such a great solution in mind but I think mypy should be able to verify each exception type is handled at some point in the stack. I know that it sounds vague, but these are my current unorganized thoughts.

Exceptions are always handled: Python exits while telling you about the exceptional situation.

If you’re saying that I must handle an exception in my code rather than crash because my “fail early, fail often” design choices offend your religious preferences… then keep it to yourself and out of PEPs.

No I'm not saying that at all, I'm just saying that if you need a function to handle all exceptions, the type system should be powerful enough to express that. E.g. in a webserver if you have a handler that needs a wrapper like:

    def wrapper():
        try:
            return handler()
        except Exception:
            logger.exception("unknown exception")
            webserver.status = 500

the type system needs to be able to determine that "f doesn't raise an exception". For example, one way to do this can be that all functions by default raise exception and we type:

    def handler() -> T: ...

    def wrapper() -> NeverRaises[T]: ...

then we have

    webserver_add('GET', '/handler', wrapper)

so that

    def webserver_add(method: str, path: str, handle_func: Callable[[], NeverRaises[T]]) -> None: ...

which is type safer.

Of course, here we need to specially handle `KeyboardInterrupt`, signals and exceptions returned by `logger` etc. I would personally recommend ignoring `KeyboardInterrupt`, and signals and type annotating `logger.exception` as `NeverRaises`. 95% is still better than 0%.

> I'm just saying that if you need a function to handle all exceptions, the type system should be powerful enough to express that.

I disagree, in part because “handles all exceptions” is a lie; exceptions can occur at any point, including in exception-hnadling code.

It is not possible to have a Python function which provides the guarantee you want, so it makes no sense to have a Python type system which expressed it: it will either be never used or a lie.

If you think you need this guarantee, you need to step back and ask what the functional requirement actually is and find a different way of meeting it.

Reply on news.ycombinator.com