Hacker News Reader

Comment by morning-coffee | Hacker News Reader

I appreciate the author's efforts and amount of time that went into this. But, IMHO, there are some things that are just plain bad advice:

e.g. https://www.lurklurk.org/effective-rust/panic.html

  "Another sensible use of panic!, even in library code, is in situations where it's very rare to encounter errors, and you don't want users to have to litter their code with .unwrap() calls."

The litmus test for panic! vs. Result<T,E> is not rarity of occurrence, it's whether the condition represents a programming bug or a recoverable error. A good treatise on this topic here: https://joeduffyblog.com/2016/02/07/the-error-model/#bugs-ar...

View on HN

IMO (systems programming background), the litmus test for panic! vs. Result doesn’t exist. Don’t panic.

Say you're implementing quick-sort, and you're checking the pivot value like this:

    if (array.len() >= 2) {
        let pivot = array[array.len() / 2];
        ...
    }

Those brackets could panic, if the index was out of bounds! Of course you can tell locally from the code that it can't be out of bounds. But if you're really not allowed to have panics (and equivalently array accesses with square brackets, as those can panic), then you have to write this code instead:

    if (array.len() >= 2) {
        let pivot = match array.get(array.len() / 2) {
            Some(pivot) => pivot,
            None => return Err(InternalQuicksortError("bad index somehow")),
        };
        ...
    }

You do this all over your codebase and it gets hard to read very quickly!

EDIT: clarified code

There are way too many replies here which seem like they fundamentally don't understand that you can't actually write an algorithm to solve the problem they imagine is easy.

Rust does have Results that it knows can't fail - for genericity reasons - these are Infallible results, for example try_into() when into() would have worked is Infallible, Rust uses an empty type (equivalent to but for now not literally identical to ! aka Never) for this, so the compiler knows this type can't be reified, it needn't do code generation for this never-happens error.

But there's a crucial distinction between Rust's compiler can see this is Infallible and I can show it won't fail and Rice's theorem means that gap is insurmountable even just in principle.

I’d be curious to see if the optimizer couldn’t detect in this instance that that code is, in fact, unreachable. It seems to me like it should detect it with ease.

I will concede that the “you should never get here” type errors are tempting to panic on. But I have seen so many instances where the “you should never get here” code does execute. Memory corruption, access by other processors, etc., could make this check (which should never happen!) actually fail at runtime. If one of those happens in code I wrote, I would rather be alerted to the error, without crashing, if possible.

A lot of the appeal to “panic on error” IMO is to reduce developer cognitive load. As a developer, it’s inconvenient to consider all the errors that can actually happen when programming. Allocations, array accesses, I/O, and other errors programmers want to ignore, do happen. It’s annoying to think about them every time we write code, but I’d rather have something that forces me to consider them, rather than be bit by something that I designed out of my consideration.

This preference might change depending on what I’m writing. For a one-off script that I need to spin up quickly, I don’t really care. For code running on a device I may not get to service for 5 years, my opinion would be different.

Wait hang on: your code hit a case that you know means something like memory corruption happened, and you want it to keep executing? If there's memory corruption, I want the program to stop ASAP so that it does as little damage as possible!

FYI Rust panics and illegal `[]` accesses will tell you the file & line number where it happened.

Some people do indeed want this as far as I know. I believe it is what the Linux kernel wants for example. I'm not aware of any other projects that want the same thing.

> A lot of the appeal to “panic on error” IMO is to reduce developer cognitive load.

Cognitive load is one of the main blocks to development. Do not diminish the importance of lowering cognitive load

> This preference might change depending on what I’m writing. For a one-off script that I need to spin up quickly, I don’t really care.

Yes, absolutely. Trade offs

> A lot of the appeal to “panic on error” IMO is to reduce developer cognitive load. As a developer, it’s inconvenient to consider all the errors that can actually happen when programming. Allocations, array accesses, I/O, and other errors programmers want to ignore, do happen.

Rust has the ? operator to address the common pattern of returning a failure condition to the caller. There's effectively zero cognitive load involved, since compiler hints take care of it when writing the code.

> I’d be curious to see if the optimizer couldn’t detect in this instance that that code is, in fact, unreachable.

Probably, but that should be a job for the type checker not the optimizer. Ideally, there should be a way of creating statically verified asserts about program values, and plugging them in as preconditions to function calls that require them for correctness.

If only there was some way to propagate the range checks...

    let lo, hi = array.bounds()
    match lo < hi {
        None => array,
        Some(lo, hi) => {
           let pivot_index = lo.avg_with(hi)  // guaranteed to be in bounds
           let pivot = array[pivot_index]     // never panics, but the index type is opaque, not usize

           ...rest of the qsort here
        }
    }

You're still using `array[index]` syntax though. That comes with a panicking branch. The optimizer might elide it, but it might just as well do that in the original code.

I do not believe you've rebutted the main point here. At best what you've done is a show a better way of guaranteeing that indices are correct. But you still need to deal with the fact that index notation comes with a panicking branch.

> That comes with a panicking branch

Not necessarily? Indexing is overloadable, so nothing stops one to write an implementation that'd use an unsafe block without any checks/panics whatsoever (because there are static guarantees that those would be unnecessary).

Apologies for the verbose response, but I just don't see how to avoid it because people constantly get tangled in knots in this sort of discussion.

I think this is continuing to miss the forest for the trees. The original code snippet could also just use `unsafe` to elide the panicking branch and it would still be just as correct while satisfying the requirement that there are no panicking branches.

But what's actually happened is that you've traded "panic when a bug occurs" with "undefined behavior when a bug occurs." Both things are valid choices depending on the circumstances, but the latter is not a realistic escape hatch out of the discussion at hand: whether one should completely elide all panicking branches.

The comment that kicked off this sub-thread:

> IMO (systems programming background), the litmus test for panic! vs. Result doesn’t exist. Don’t panic.

The "Don't panic" advice is correct but ambiguous on its own. If it's referring to the behavior of a program, then yes, absolutely, don't panic. Or as I like say, "if a program panics, it should be considered a bug." But if it's referring the source code, as in, there should be no panicking branches, then that is absolutely wrong. Neither the standard library nor any popular Rust library follows that practice. And they shouldn't.

I interpreted "Don't panic" as the latter meaning because of the claim that "panic! vs Result doesn't exist." That only makes sense in the latter interpretation. In the former interpretation, one does need to contend with a "panic vs Result" choice, as it's often a balance between convenience and how it's usually used. For example, indexing a slice with a `usize` panics.

So either the former interpretation was meant and the poster is confused (or just misspoke), or the latter interpretation was meant and is divorced from reality.

I'll post a link to my blog on this topic yet again, because I'm pretty sure it will clarify the situation and my position: https://blog.burntsushi.net/unwrap

This is possible using branded indices.

https://plv.mpi-sws.org/rustbelt/ghostcell/paper.pdf https://gitlab.mpi-sws.org/FP/ghostcell/-/blob/master/ghostc...

Yes, indeed. And it's not even a novel idea, my example is lifted straight from one of the references of the paper you've linked (namely, Kiselyov & Shan, "Lightweight Static Capabilities", 2007).

I personally think that taking an optimization (e.g. boundary checks elimination) and bringing it — or more precisely, the logic that verifies that this optimization is safe — to the source language-level is a very promising direction of research.

Well all you have to do then is make it not hard to read :-)

   #[derive(thiserror::Error, Debug)]
   enum Error {
     #[error("bad index somehow")]
     BadIndex
   }

   // ...

   let pivot = array.get(array.len() / 2).ok_or(Error::BadIndex)?;

How does anyone on the stack above handle this error? i.e. what can be done programmatically to deal with it?

I claim this is far worse than panic in this case... you've now introduced a code path variant that folks above think is "legitimate" or caused by some input or something in the environment that could be changed to make it go away... but that's not the case here... the only thing that can be fixed is the code in question to not be in this region if the array length is 2 or less. It's a plain old "bug" and the only cure (other than more cowbell) is to modify source and recompile.

> How does anyone on the stack above handle this error? For a web application, you respond to the request with 5xx error.

Applications do many things. A degraded state (e.g. a single endpoint being broken) is often preferable to a full crash. It's very little effort to opt in to panics by calling unwrap(). It's a lot of effort to recover from panics. Let me, as the caller, make that decision.

But any standard web framework already would use a panic handler to turn a panic within application code to a 5xx error.

Here's a discussion on actix-web and panic handlers: https://github.com/actix/actix-web/issues/1501

Some technical limits, a lot of cultural opposition. While it is possible to have a panic handler, it's generally viewed as a bad idea. Not everything is UnwindSafe, there are limits to how much a panic handler can do, concerns about memory leaks.

Again, the caller can turn it into a panic easily enough if that's what they want. leave the decision in their hands.

You can convert the Option to a Result where the None becomes the error and then propagate from that.

This is basically how you are using this Option by the way, and while it's possible, you have to consider why the original author decided to return an Option and not a Result: It's because he wants you to handle that in a way that doesn't fail (ie: an error) but instead consider it as a non-failure possibility.

Maybe my mind has been poisoned by a few years of Scala, but that just looks like normal code to me. Bundle up those errors and return a useful message to the user about why it failed, call it a day.

The point is that the code literally cannot panic under any circumstances. Just because there's a call to `unwrap()` or `[]` doesn't mean it's actually possible to trigger that panic. I made that more explicit the code, in case that wasn't clear.

If there's any question as to whether a line might actually panic or not, then absolutely, generate helpful error messages. But when you can tell through simple local reasoning that the panic will never happen, you can just use square brackets. It's OK.

> when you can tell through simple local reasoning that the panic will never happen

A problem is that you may be able to tell now, but as code changes and functions grow and split, that reasoning may grow less simple and less local without any changes of those lines in particular.

The odds of that, and the degree to which it matters, are of course both spectacularly situation dependent.

And if my grandmother had wheels she'd be a bicycle!

The point being, take context into account. You can't code like everything everywhere is going to get modified to be worse.

I agree, I was just surfacing a sometimes missed piece of context.

For the first time, I find myself wanting the equivalent of a :thumbs-up: reaction emoji on hn.

The point is that the language has decided that some kinds of builtin operations can panic, in the interest of developer ergonomics. The alternative is that every indexing operation returns a Result, or you write 4 lines of code instead of 1 for every indexing operation. So the notion that the programmer should never write "panic!" in their code does not fully address the underlying problem, if the reason for not writing "panic!" is "library code should never panic".

Panics have a place in systems programming — all operating systems panic when fundamental guarantees are violated.

I think you mean that CPUs have low level exceptions/interrupts. 'Panic' in this case is a rust specific term and is higher level.

Panic is not a rust-specific term, it generally refers to software halting intentionally because something has gone so wrong that you can’t reasonably recover. For example, some safety invariant is violated or core data is corrupted. Kernel panics (also called bug checks or BSODs in Windows, same concept) exist in all OSes by necessity.

panic is also a linux specific term.

When rust panics, it shuts the program down.

When linux panics, it halts the machine - for fundamental things like data corruption detected, and we can't continue to operate and risk corrupting the disk. Just like Windows has the BSOD.

And you'll find equivalent panics in e.g. Linux.

Certainly not. See: https://blog.burntsushi.net/unwrap/#why-not-return-an-error-...

But also the rest of the blog post should help clear up the confusion.

This is the right answer. A panic is a bug. It's always a bug.

As an outsider, is panic() like assert()?

assert!(cond) in rust is basically

    if !cond {
        // I ad-libbed the exact error message
        panic!("Asssertion failed {cond} was false, line/file information, etc")
    }

panic!(message) is "either throw an exception containing message, or print the message + maybe a backtrace and abort the process".

You can use compiler flags to guarantee that it aborts instead of throwing an exception, you can't use compiler flags to guarantee that it acts an exception, sometimes rust will just abort the process (for example if you panic!() while you're already unwinding because of a prior panic!()).

If nothing catches the exception (and that's usually the case, by convention), the runtime will print the message, maybe a backtrace, and kill the thread that paniced.

assertions often get turned off in production/release code, panics do not.

Not in Rust. You can use debug_assert if you don’t want to assert in prod tho

I meant generally, you are absolutely correct about rust.

It is like printf to stderr and exit(1)

If you are building application software like a web framework, panicking and then dealing with the issue using a global exception handler to return 500 is often the easiest. There was no point in littering the code with match Result => err return http.status500 like bad Go.

This is sometimes called the diaper (anti)pattern - because it catches all the poop. It works great - so long as the only exceptions your program ever throws are ones you are deliberately throwing to the global error handler. Given that, go for it. ;)

(That would be the point of exceptions that make the correct thing the majority of times, and why I think they are superior, checked exceptions that it. They are completely analogous to Result types, but are properly supported by the language and can have as small or big scope as needed. I am really hopeful that they will have a resurrection with languages with effects)

You have a point but so does the OP. The classic example that follows the OP's recommendation is allocation failures. Of course, not everyone is happy that String or Vec will panic on allocation failure and wish allocating methods returned a Result instead. But changing all allocating APIs to returning a Result would make others unhappy given how rarely a program can truly recover from an allocation failure.

BTW, overcommit/oomkiller aside, recovery from allocation failure in Rust can be easy and reliable.

There is an assumption carried over from C that code paths handling OOM errors are untested and likely broken. However, Rust doesn't have manually-written error handling paths like that. It has `Drop` which is always correctly inserted by the compiler, and regularly tested on normal function exits.

Rust does have manually-written error handling paths like that. See for example the panic handling in Vec.retain_mut: https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#1577

I doubt most crates handle these scenarios correctly.

This is limited to unsafe code, and the "exception safety" is a known problem to deal with. It can be tested without having to trigger OOM.

If you are writing a library, whether or not .unwrap() is sensible is not up to you - it's up to the user.

This is wrong. Plenty of Rust libraries, including std, correctly use unwrap: https://blog.burntsushi.net/unwrap/

Is there a tool that can assert a library doesnt/cant panic?

https://docs.rs/no-panic/latest/no_panic/ might be what you're looking for

Just to jump in from the peanut gallery: this kind of discussion, about the "right" way to do things in a complicated language with lots of choice, prompting digressions about conventions and mildly-kludgey third party "soft" solutions to what would seem to be generic problem...

...is exactly where C++ was in 1995 when Meyers published Effective C++.

The specifics of the argument notwithstanding, the very existence of this discussion validates the need for this book. And it also says some somewhat awkward things about the direction in which Rust is evolving.

  > "the very existence of this discussion validates the need for this book."

Or it could also mean that some folks involved in this discussion haven't yet read the chapter[1] in "The Book" that explains when to panic and when not to[2]?

[1] https://doc.rust-lang.org/stable/book/ch09-00-error-handling... [2] https://doc.rust-lang.org/stable/book/ch09-03-to-panic-or-no...

This discussion exists for any programming language that qualifies for the label "useful for 1 or more tasks".

Not at this level of pontification. Python and C and Java and .NET have achieved much success without this kind of "the community can't decide on the right way to do this very fundamental thing[1]" kind of disconnect, largely by scoping themselves such that the tradeoffs are made internally to the language runtime and not a subject for debate.

And, fine, Rust is more ambitious, just like C++ was. But that too has tradeoffs in language complexity and evolutionary cruft, something that is often cited as an advantage vs. C++. But as we're seeing here, it's not really. It's just that C++ is a few decades farther along on the same curve.

[1] In this case, literally, how to handle a runtime error.

This is absurd. The community has decided. Go look at any popular Rust library. The panicking strategy will be the same in all of them: if a panic actually occurs at runtime, it's considered a bug. But libraries still use unwrap in the same way asserts are used.

I've asked many people to show me real Rust code that does it differently, and I haven't found any takers.

The confusion here is mostly in terminology and in the "peanut gallery."

This has literally been a solved problem since Rust 1.0. I know because I was there and published a blog post on exactly this topic.

So, what's actually the correct answer? Or should we go and read the whole book?

The joke is that there is no correct answer, and there "should" be, which is why Rust needs books now. Things always get worse and not better over time in this space.

Instead of old and wise, languages only get old and senile. :D (For which there is but one cure: breaking backwards compatibility.)

> The litmus test for panic! vs. Result<T,E> is not rarity of occurrence, it's whether the condition represents a programming bug or a recoverable error.

Because that exact same conceptual separation worked so well for Java with checked vs unchecked exceptions...

Everyone just started using unchecked exceptions because they provide an easier coding experience.

Also, there's legitimate situations where the library cannot make that decision, but rather the user. As someone else says in another example, who are you to say that my request to allocate too much memory is a panicable offense? What if my program can, in fact, recover from that situation?

At least in Java, catching checked vs unchecked exceptions is the same if you do choose to handle them.

> > The litmus test for panic! vs. Result<T,E> is not rarity of occurrence, it's whether the condition represents a programming bug or a recoverable error. > Because that exact same conceptual separation worked so well for Java with checked vs unchecked exceptions... > Everyone just started using unchecked exceptions because they provide an easier coding experience.

Indeed. That's a problem with exceptions and checked exceptions and the choices in Java around that, not the idea that operational and programming errors might be handled differently.

> Also, there's legitimate situations where the library cannot make that decision, but rather the user.

What you're describing is that different components may choose to treat these separately. That's fine -- there doesn't need to be an objective answer. You can have one library say "allocating too much memory is not an error we care to deal with and we treat that as a programmer error". And people using that can be told that's a limitation. That's fine. All components have limitations. Another library that implements the same thing can say "we treat allocating too much memory as a recoverable operational error and express it in this way". It's all tradeoffs.

That also doesn't mean _all_ such cases are subjective. Another comment mentioned an index out of bounds in quicksort. That's completely within the control of the implementation and in most contexts there's no reason that should ever be a recoverable error.

> Everyone just started using unchecked exceptions because they provide an easier coding experience.

I think that's true, but I think there's some ambiguity about what sort of "easier coding experience" mattered. I feel like it's often portrayed as "too lazy to write the annotations", but in practice the language to describe exceptions is often too limited to express what we'd want. As a trivial example, we'd like to be able to say "map() can throw anything its argument can throw". That we can't say that means a programmer working with checked exceptions needs to either catch and suppress things they shouldn't be suppressing in that function passed to map(), or build clever (and possibly inefficient) workarounds to extract the exception(s?!?) anyway. All of that has drawbacks enough that the downsides of unchecked exceptions may be the correct choice, not merely the lazy choice.

> Everyone just started using unchecked exceptions because they provide an easier coding experience.

This is because checked exceptions, contrary to Result, are much more limited/annoying e.g. they don't compose well with lambdas, can't be generic, and don't offer those nice functional combinators.

> Java with checked vs unchecked exceptions

Java doesn't make it nice to deal with exceptions though. Converting a checked exception into an unchecked exception is incredibly wordy:

    int output;
    try {
        output = doSomething();
    } catch (IOException io) {
        throw new RuntimeException(io);
    }

vs Rust's method of defaulting an error result to a panic:

    let output = doSomething().unwrap()

https://doc.rust-lang.org/std/result/

Its very different from Java.

In Java and many other languages, the expectations are declared at the callee site, which is a completely wrong place to do it. Only the caller knows whether the situation is expected or not.

Lets say I'm trying to get the element at index 20 of some array-like datastructure.

Lets say that returns a `Result<T, E>`.

Lets add another twist: I've already checked whether the length is > 30 for other resons in that same block. Therefore, I know (if borrowing mechanisms ensure the absence of concurrency issues) that getting the 20th element will not cause an error. In this case I can use

  my_obj
    .element_at(20)
    .expect("Unexpected missing element at index 20 even though number of elements is > 30")

As a caller, something is very wrong in this situation. If so, I can make the choice (doesn't work for all types of programs) to abort immediately.

edit: see other comments in the thread for a more believable quicksort example, where you are getting the element at `len/2` as pivot.

This is a somewhat certain situation. You can also use this in softer situations, like e.g. a program that just can't run if its data file (large language model files, for example) cannot be found in `$PWD` because say, the docker image is always built in a way that includes it and you wrote it to only run within that image. As a caller, its up to you to decide whether this situation is expected / recoverable or not. (Yes you might criticize that rigid choice, but if the choice is correct, so is the behavior to abort if the condition is not satisfied)

You can also decide that the callee doesn't know whether the error is expected and "propagate" the error further by ensuring the function returns a Result<T, E> using the `?` operator.

Rust is one of the rare languages that gets this right. (Swift does too [1] - i am not quite aware of others)

[1]: https://docs.swift.org/swift-book/documentation/the-swift-pr...

Checked exceptions aren’t really compatible with generics. You can’t pass a lambda and have the compiler infer its exception list now applies to the caller.

aye - in Java, this inevitably leads to strange catch Exception/RuntimeException statements all over the code. In practice, there are very few/no reasons to order a program crash. Programming errors are inevitable on a large code base, we learned the hardway in kernel development that Blue Screen Of Death is not the correct outcome for an error.

> Everyone just started using unchecked exceptions because they provide an easier coding experience.

Yes, in much the same way that no longer checking for error codes provides an easier coding experience.

But it makes your code more crashy.

Reply on news.ycombinator.com