Zero-Cost Exceptions and Error Interfaces | Hacker News Reader

Zero-Cost Exceptions and Error Interfaces

sourcery.ai

36 pointsrekahrv42 comments

Exceptions are an anti-pattern. If a function can encounter an error, it should expose this fact through its interface (specifically its return type).

For example, Rust has a Result type [1], so this function would return Result<Item, ItemNotFound>. This forces the caller to think about what to do in case of an error and specify what should happen.

[1] https://doc.rust-lang.org/std/result/index.html

Even Rust has panic for things like out-of-bounds access. In fact, Rust's panic / Result is actually very similar technically to Java's checked / unchecked exceptions. I'd argue that this is more a difference in usage and culture, with likely influence from the fact that Java makes it easy to catch unchecked exceptions, so many prefer unchecked exceptions to avoid being forced to think about what to do in case of an error (which, of course, means that probably the wrong thing happens then).

Also, Rust culture (IMHO) tends to be more strict about technical errors, probably because it is applied to more low-level problem areas. If high-level business logic is cluttered with technical error handling in every other line, it becomes near impossible to read and maintain, so other patterns are applied (e.g. atomic transactions that are undone when something fails).

> I'd argue that this is more a difference in usage and culture

Usage and culture and affordances, as in:

- the stdlib doesn’t signal errors by panic-ing

- rust learning documents drive users towards Result and Option

- the standard library provides APIs to manipulate results in ways Java is utterly missing e.g. map_err, ok, ok_or, ?, …

- because results are reified values, the language allows abstracting over results (creating macros or functions around them), as well as providing utilities around them (e.g. eyre, thiserror, anyhow, …)

- because results are reified values, they can be ignored until relevant, an `Iterator<Item = Result<…>>` is just an `Iterator<Item = _>` until you actually need to process the result.

- panics have very little signaling power, technically your panic can carry a payload but I’ve never seen anyone go beyond a message

Also rust panics are explicitly noted to not necessarily be recoverable from, so they can not be used for error signaling: whoever compiles the program can set panic=abort, and now you have no error handling at all, the program just straight dies.

And even if you actually, genuinely, want to use checked exceptions in Java, it’s hell, because it does not mesh with the rest of the language. Just look at the contorsions necessary to get checked exceptions through Stream APIs.

Checked exceptions are not necessarily bad in and of themselves, but Java’s implementation is so awful it has completely poisoned the field. And frankly it just… doesn’t seem like a very useful thing to put work into: you can just use exceptions-flavoured results à la Swift or Zig if you like the “look” of exceptions.

Nim does “checked exceptions”-ish via its effects system and {.raises: […].} pragma. Though it’s not just limited to exceptions. Can be used for all sorts of useful things!

To me, the key problem with Java’s error handling is that there’s no special consideration given to functional interfaces like Callable/Runnable/etc — so you effectively cannot throw a checked exception from within a lexical closure passed to a Stream.map, ExecutorService.submit, etc: trying to do so gets you a compile error.

This was worked around in the design of CompleteableFutures, where the closure must cyclically capture its own future in order to be able to call .completeExceptionally on it; but that requires that every use of functional code essentially subvert Java by having a try-catch at the root of the closure’s AST that turns propagating exceptions, into, essentially, results, via a side-channel; and then the caller of CompleteableFuture.get gets the side-channel exception value thrown back at them and propagating again. Honestly a mess—and people think Golang’s little “if err != nil” checks are bad!

(What should actually be happening is “exception generic auto-deduction”: anything that accepts Callable or other functional interfaces should actually accept a (currently-impossible) type “Callable throws <T>…”; and then the list of checked error types of the instantiated object should be deduced from what the called code actually does—as Java perfectly-well knows how to do, in order to assert compiler errors about checked exceptions in the first place. This would also require you to be able to define methods that “pass along” checked exceptions without knowing what they are, though — and without just declaring you throw Throwable and thus discarding the exception typing of the callee — in order for the framework code that takes these Callables to be valid.)

masklinn already made lots of good points. I'd add that panics in Rust are for intended for non-recoverable errors (like memory allocation failures, out-of-bounds access) and under most use cases are equivalent to abort(). There are mechanisms to catch panics in Rust, but the docs state:

"It is not recommended to use this function for a general try/catch mechanism. The Result type is more appropriate to use for functions that can fail on a regular basis. Additionally, this function is not guaranteed to catch all panics, see the “Notes” section below."

> atomic transactions that are undone when something fails

This is exactly what many business apps do frequently, through the use of database transactions.

[1] https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

One should also note that while Java famously takes the blame, checked exceptions appeared in CLU, were adopted by Modula-2+, Modula-3 and C++, before landing into Java's design.

And while C++ has moved away from its original design, it kept the variant of "no exceptions" or "expect any kind of exceptions", and still there are ongoing discussions of eventually getting something similar to Swift's model.

To add to that, Java doesn’t make it convenient to have a place that catches checked exceptions only, because the inheritance hierarchy is the wrong way around for that.

Also, the type system isn’t strong enough in most cases to express something being generic over the exception type, so lots of interface implementations end up having to wrap every exception in a RuntimeException anyway.

If you are looking to catch only checked exceptions of unknown type, it's easy enough to first catch and rethrow Error and RuntimeException, and then catch Exception and do whatever. The hierarchy is garbage, but at least it's fixed in stone. Not super useful though if you know the exception types.

There are plenty of code bases that are dramatically simpler when exceptions are in use, especially if you just want to read and understand the happy path. I'm tempted to give an example or two but I'm sure most readers know that really.

There is definitely a trade off for efficiency and guarantees about all error conditions being handled. That means that exceptions aren't appropriate for all situations or perhaps even for all languages. But taking such a hard line against them is just as naive as using them too much. (It's always suspicious when you see someone making a sweeping declaration like this about engineering trade offs.)

Python is not Rust. Its goal is not to be hardened and super reliable. Its goal, at least sometimes, is to maximise developer productivity. Imagine telling a Python developer who's just thrown together a quick script that, actually, no, you're going to have to waste time making it more verbose so that it satisfies some reliability constraint you don't need. It just doesn't make sense.

Rust also has a much more rigorous type system than other languages - so yes in rust exceptions should be considered an antipattern.

The implementation proposed in the article seems very reasonable python.

Writing code for language X in the style of language Y is usually an antipattern. When Rome do as the Romans do.

1000%

In C, if it can fail, my function always has an error out parameter.

  void mtt_read_user_file(char* path, mtt_error_t* error);

The ease of use benefit of having a unified way of checking for errors far outweighs any performance cost.

My errors:

- are binary. "FAIL" vs "SUCCESS"

- hold a chain of user friendly error strings

- have caller controlled behavior, such as turning off error strings to save perf

- can also hold a single error code

- supports being fully preallocated, which I always do at thread creation time. I only need one error object per thread.

I'm quite proud of the error handling in my C code.

How can you argue that a result type is more forcefully thought about than checked exceptions?

If that was the goal, shouldn't we like checked exceptions the best?

The point of the article is that, at least in python, skipping the result check is cheaper in the happy path and slower in the exceptional case which is a useful trick. You haven't addressed that trade-off at all.

Checked exceptions like in Java have terrible ergonomics and require a lot of special handling by the language and don't work well in combimation with other language features. Return values also have their cavets, but I think languages like Rust are doing well enough so that their ergonomics are way above what you can get with check exceptions, even with a good implementation.

Sure you you start with an error monad, then you add do notation and then you end up with (checked) exception syntax and semantics. Then the cycle repeats.

At some point you realize that exceptions, error codes and the error monad are all equivalent except for syntax and with enough syntactic sugar it should be possible to unify them.

A language antipattern maybe, a programming antipattern, no. Python isn’t ML – it got pattern matching only very recently. Without it, and in a language where type tests are often a bad smell, exceptions are perfectly reasonable.

A machine language instruction like

   load r0, some_location

may encounter the error that some_location is in a not-present page that needs to be faulted in.

Should the instruction expose that through its interface, like some special value stored in r0, or a CPU flag being set that needs to be tested?

Loading a not-present page is typically handled transparently by the OS. Exposing it to the userspace program isn't really useful.

I'd suggest to change your example to faulting for a page that doesn't exist in swap either, so a decision has to be made whether to set a flag or e.g. send a signal to the process.

Loading a not-present page is handled by an exception being signaled, which the operating system has to handle with code.

The transparency is a great benefit, which can be attributed to exception handling.

> I'd suggest to change your example

That is hardly required for my point.

> send a signal to the process

That's another exception mechanism.

So you mean you advocate for checked exceptions?

Like Java's "throws" keyword?

https://www.baeldung.com/java-checked-unchecked-exceptions

I raised the same objection in another subthread and got reminded how Java's checked exception, while attacking the same problem as Rust's Result<> type, are really abysmal from a usability POV. Now I remember why I never used them...

Checked Exceptions are really not worse than error result types unless you abuse them for normal control flow. Normally, Rusts exception handling is almost exactly isomorphic to checked exceptions in Java.

For general results cases (i.e. non exceptional cases), there exist a million small solutions in java.

The problem with that is that checked exceptions ask you to be treated as normal (non-exceptional) control flow. Hence the appeal of unchecked exceptions because they allow you to treat exceptional control flow as exceptional. The comparison of checked exceptions with result types is because they are competing solutions for normal control flow.

In that other subthread, several problems are mentioned that occur even when you use checked exceptions only for exceptional control flow. The big ones that come to my mind are that functional-style methods like .map() and .filter() and the corresponding interfaces like Function<> and Predicate<> cannot deal with checked exceptions at all; the other (related) is that declared exception types cannot use type variables.

With result types, error handling becomes non-exceptional control flow and you can use .filter() and .map() to handle the error cases themselves. With Java's unchecked exceptions, error stay exceptional and the functional-style methods pass them on transparently. Checked exceptions cannot do either, and are incompatible with functional-style methods.

> Normally, Rusts exception handling is almost exactly isomorphic to checked exceptions in Java.

yes, that's the problem ahha

Probably the only feature I like about Java.

It's unfortunate that Java's checked exceptions do not work in Java's functional APIs like Streams.

Yes.

I personally find Rust's way of doing things superior (for reasons masklinn mentioned in his comment), but it's basically the same principle, just realised in a different way.

I believe Rust has a concise syntax (?) to let exceptions bubble up. Does Java offer a way to ignore checked exceptions at the current level?

> Exceptions are an anti-pattern. If a function can encounter an error, it should expose this fact through its interface (specifically its return type).

this is how you end up with java checked exceptions where 10% of the codebase is programmer trying to circumvent them and turning errors into silence because of how bad they are

Just a small suggestion to consider: If the title was "Zero-Cost Exceptions and Error Interfaces in Python" I would have received it in my personal Hacker News feed in Telegram (https://github.com/lawxls/HackerNews-personalized) as I do have "Python" keyword added. And there's also email notification services people use which might have Python as a keyword.

Thanks for providing further resources btw, added Sebastian Witowski presentation to "watch later" list :)

Thanks a lot, that's a very helpful tip. :-) We'll adjust the title for future posts. (And I'll set up such a keyword-based notification for myself. :-)

Sebastian's talk is awesome indeed. I learned a lot from it about how Python works without going too much into the implementation details.

How is "dictionary[key] = None" equivalent to dictionary[key] not existing?

The article never claims that anywhere.

That makes it hard to interpret your comment because there are a few places where the article slightly conflates a non-existent key with value == None and maybe you're obliquely referring to one of those, but I'm not sure which one. All of them are OK so long as the dictionary doesn't have having any values equal to None, which it should really spell out but is obviously implied. Actually, most of them even require that none of the values are falsey (e.g. 0, empty list, None, or indeed False).

It would actually be possible to work around that but still fundamentally use the same ideas by using a sentinel value:

    # At file scope, not exposed
    _not_present_sentinel = object()
    # Version B
    def read(self, id_: str) -> Item:
        result = self.items.get(id_, _not_present_sentinel)
        if result is _not_present_sentinel:
            raise ItemNotFound(id_)
        return result

The article starts with a poll showing Versions A), B) and C). Implicit in that poll would be that all three "versions" produce the same behavior.

Options A) and B) conflate None with non-existent key: if the key is set and has value None, they will return ItemNotFound. Option C) on the other hand treats them separately and will happily return None (instead of raising exception) when the key exists and its value is None.

In general it’s not, although for a number of languages (e.g. java, ruby, go) it kinda is.

Here the dictionary is supposed to hold Item values, not Optional[Item], so None would be the signal of a missing item. Think

    Lookup k -> Map k a -> Maybe a

Not sure how that came about tho, as the article specifically argues against returning a None for missing entries?

Depends on the language.

In Python, dictionary[key] will raise an exception if the key doesn't exist. If there is a value it's returned, even if that value is None.

As far as perf goes, a callee raising an exception is never the answer.

The perf arguments are a sham imo.

A callee cannot know how many times it is going to be called, only a caller, or a caller's caller, etc, can know that.

I like how the closest thing to a "correct" answer gets dismissed almost immediately with fairly weak reasoning.

You're adding type hints so they're not going to be blind sided anyways, just return a union of Item and None. If None is a valid value then use a result type.

Exceptions are for exceptional cases isn't just a performance thing, it's a reasoning thing: You're jumping out of the established control flow and there should be a very good reason for that.

If you're struggling with handling None even when you know it's a valid return value, living in a codebase that overuses exceptions is going to be 10x worse.

> Exceptions are for exceptional cases isn't just a performance thing, it's a reasoning thing: You're jumping out of the established control flow and there should be a very good reason for that.

Python uses exceptions for all sorts of things like to signal the end of an iteration which isn’t exceptional at all. That ship sailed a long time ago.

You are assuming that a missing item is a normal (as in "not exceptional") case, but that is entirely application-dependent. But then, the article doesn't give any context either -- it just throws an exception in every variant of the code, so the most likely assumption here is that missing items are exceptional.

Except the article quite literally say None is an option, except <insert not great reasons>. That wasn't an assumption on my part.

If the missing item wasn't exceptional they would have just said that.

Also if even if it were exceptional, you'd still served extremely well by a Result type.

Instead of just guessing where the landmine is sitting the type system can help you. Python explicitly opted out of type hints for exceptions to avoid a Java-style "checked exceptions" world.

To be honest, the example given (a "read" method that wraps direct access and raises a custom exception) does not inspire confidence that the item is expected to be there more often than not. There's certainly too little context to assume anything.

Expected or unexpected, either way there are two paths; I would return a Result/Option type.

  def read(self, id_: str) -> Item | None:
    ...

Reply on news.ycombinator.com