Hacker News Reader

Comment by RantyDave | Hacker News Reader

"A simple cache returns None both for a missing key and for a key that maps to None."

No, it returns KeyError. Or at least it should.

it’s maybe less “pythonic” but at $dayjob we’ve very actively moved away from exceptions for things in favor of things that are statically type checked. too many things that become runtime bugs instead of type checking bugs.

with match now being available, we even return explicit error objects and the ergonomics are pretty good (reminds me of rust).

How are these two things related? If you don't use exceptions, you just have to implement them yourself by manually bubbling up the error, all the way up the stack, rather than using the dedicated side channel to do so.

The problem I see is there's no way to enforce the check that you actually handled/bubbled up the error. With exceptions, you just crash if you don't handle it, which is much preferred if determinism is the goal. Is there some way to use the type system to do this? Maybe incoming are UnhandledResult outgoing are some HandledResult or something like that?

If you're going to use the returned value you'd probably return the moral equivalent of Rust's Result/Haskell's Either/etc. types. As long as the returned types don't happen to share the necessary API(s) the type checker should yell at you if you don't branch on the returned value.

I don't think Python has the equivalent of C++'s [[nodiscard]] or Rust's #[must_use], though, so if there are cases where the return value can legitimately be ignored then return values risk missing errors that would show up under exceptions.

Yeah, this is basically what we do. It ends up a bit more ergonomic to not have explicit result types because union types are pretty easy in Python. For example, we have functions like

    # courses.py
    def create(...) -> Course | ErrInvalid:

and they get used like

    match courses.create(...):
        case courses.Course() as course:
            # We use `course` below.
            pass
        case courses.ErrInvalid() as err:
            # Error conditions are usually translated into early returns
            raise fastapi.HTTPException(
                status.HTTP_422_UNPROCESSABLE_ENTITY, err.message
            )
    
    return APICourseCreateResponse(id=course.id, ...)

It has worked (for us at least) pretty well to reduce the number of unhandled errors that make their way into Sentry. The granularity of the error types depends on the need (e.g., sometimes we just have an `ErrInvalid` that returns a message which gets displayed to the user, but sometimes we'll have ErrInvalidAddress or ErrInvalidTaxCode to be more specific for the context).

And yeah, without nodiscard, we try™ to only do this on functions that return values that the caller will definitely need to use. Also combined with exhaustiveness checks on switch statements by default.

Perhaps the author has had their fair share of run-ins with libraries that didn't think their API through like that. But yes, they should.

Very many people have been taught that exceptions are bad and should be avoided, because google avoids them.

The adverse knee-jerk hate for exceptions far predates Google also saying they're bad, but certainly that didn't help.

Very many people have learnt that exceptions are bad and should be avoided, because they are bad and should be avoided. Some of those people work at Google.

Author here. Especially in Python, I think exceptions are not evil in any way but when it comes to typing they are a pain. Once gave a somewhat provocative talk about this that exceptions are gotos in a way :-) https://florianwilhelm.info/2025/04/evolution_of_goto/

I wouldn't go as far as evil but they are bad for code quality because they obscure the behaviour of functions. You never know what exceptions can be thrown. Can a function even fail? Impossible to tell. (Don't say "documentation" lol)

The standard answer is checked exceptions, which I'm on the fence about, but they don't seem to be very popular in any case. Python doesn't have them. C++ removed support for them which shows you how unpopular they were. Java has them and IIRC they were kind of ok to use in Android. Kotlin doesn't have them though so I guess the Java people didn't really like them either.

The author’s example chose to use the syntax that returns None on missing. If they wanted clarity the standard API does raise.

  cache = {“key”: “value”, “some input”: None}
  cache.get(“missing_key”)

  cache[“missing_key”]

There are better examples that could have been highlighted.

> No, it returns KeyError. Or at least it should.

Surely you meant _raises_? Or did you literally mean to return an exception class?

Yes, raises. My bad.

Reply on news.ycombinator.com