265
How One Uncaught Rust Exception Took Out Cloudflare (hackaday.com)
submitted 11 months ago by to c/technology@lemmy.world
57 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 11 months ago* (4 children)

No, it's a panic, so it's more similar to a segfault, but with some amount of unwinding. It can be "caught" but only at a thread boundary.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 11 months ago* (3 children)

    An unhanded error will always result on a panic (or a halt I guess). You cannot continue the execution of the program without handling an error (remember, just ignoring it is a form of handling). You either handle the error and continue execution, or you don't and stop execution.

    A panic is very far from a segfault. In apparent result, it is the same. However, a panic is a controlled stopping of the program's execution. A segfault is a forced execution stop by the OS.

    But the OS can only know that it has to segfault if a program accesses memory outside its control.

    If the program accesses memory that it's under it's control, but is outside bounds, then the program will not stop the execution, and this is way worse.

    EDIT: As you said, it's also an important difference that a panic will just stop the thread, not the entire process.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 11 months ago (2 children)

    Yes, it's not the same since you get a stacktrace (if enabled) and a message, but it's the closest thing you get in safe rust (outside compiler bugs). I compare it to a segfault because it's almost as unhandleble.

    Basically, you don't want a panic to crash your program in most cases. If you do, make it explicit (i.e. with expect()). unwrap() tells me the value is absolutely there or the dev is lazy, and I always assume the latter unless there's an explanation (or it's obvious from context) otherwise.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 11 months ago (1 child)

    I see you ignored my entire comment.

    I don't know what is more explicit about expect. Unwrap is as explicit as it gets without directly calling panic!, it's only 1 abstraction level away. It's literally the same as expect, but without a string argument. It's probably top 10 functions most commonly used in rust, every rust programmer knows what unwrap does.

    Any code reviewer should be able to see that unwrap and flag it as a potential issue. It's not a weird function with an obscure panic side effect. It can only do 2 things: panic or not panic, it can be implemented in a single line. 3 lines if the panic! Is on a different line to the if statement.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 11 months ago

    I see you ignored my entire comment.

    No, I responded to the relevant part. I was using segfault as a metaphor, not arguing that it's actually the same mechanism underneath. If you're getting panics in production code, I consider that just as much of an emergency to fix as a segfault, and Rust helpfully gives you stack trace info with it. It's not the same idea as an exception, which could signify an unrecoverable error or an expected issue that can be recovered from.

    I don’t know what is more explicit about expect

    It forces you to write a message, so most temporary uses will be unwrap(). I use unwrap() all the time when prototyping for the happy path, and then do proper error handling later. This is especially true in larger projects where I can't just throw in anyhow or something and actually need to map error types and whatnot. I don't use expect() much (current hobby project has 4 uses, 3 for startup issues and 1 for hopefully impossible condition) but I think it makes sense when there's no way to continue.

    But yes, unwrap() is perhaps the first thing I look for as a reviewer, which is why it's so surprising that this is the issue. At the very least, it should have been something like expect("exceeds max file size"). I personally prefer explicit panics in production code, but expect is close enough that it's personal preference.

  • permalink
  • fedilink
  • source
  • parent