[TrustPatches]

One problem I’ve experienced doing something like this is you end up with both exceptions and error values since the standard library and 3rd party libraries are still primarily exception based. You either have to live with it or create wrappers that catch errors and return them as values.

[JodieBenitez]

> You either have to live with it or create wrappers that catch errors and return them as values.

Some of us used to wrap php "errors" to convert them into exceptions. Then I switched to Python and was pleased to see the pointless distinction between errors and exceptions gone... not gonna go backwards on this.

[neuromanser]

> Some of us used to wrap php "errors" to convert them into exceptions.

Did exactly that back in the day, this comparison is flawed: PHP errors (and warnings, notices) by default went completely outside the flow of the program, and converting them to exceptions was a means of forcing developers to deck with them right away, sometimes at all.

[goodoldneon]

We write wrappers for standard and third-party libraries that throw errors. For example, we have our own dump_json function that catches-and-returns errors thrown by json.dumps.

We didn't need many wrappers given the nature of our SDK, but some programs will need many wrappers and that could get unwieldy

[dmurray]

But people are going to import your SDK, so your customers will be stuck with a mix of thrown exceptions and errors-as-values in their code.

Based on your decision to write wrappers internally, presumably you'd argue that the sensible thing for them to do is to write wrappers either for your SDK or for every other library to get back to a consistent style and less mental overhead.

[goodoldneon]

Author here!

We don't return errors in our public methods so our SDK still feels Pythonic. We're debating whether to add `_safe` suffix methods that return errors to give people the option, but for now our library only throws errors to consumers.

You might ask "well what's the point if you still throw errors to consumers?" We feel that forcing our engineers to deal with errors where they can happen is worthwhile. Our team writes a lot of Go and we love how it forces you to think about every spot that can error, so we wanted the same experience in Python

[dmurray]

OK, in that case I think it's a very reasonable choice! Perhaps it's worth clarifying that in the article.

I might express a slight preference that your internal code is idiomatic if I'm going to be poking around in there at some point. But I wouldn't be bikeshedding about your C coding style if you'd provided a Python module written in C, so I don't feel I should have a strong opinion as a user here.

[igortg]

Although I liked the proposal (the `-> User | Exception` idiom is quite beautiful), that's a deal breaker.