9 ms·
IMO (systems programming background), the litmus test for panic! vs. Result doesn’t exist. Don’t panic.
by lumb63 3y ago
IMO (systems programming background), the litmus test for panic! vs. Result doesn’t exist. Don’t panic.
- KRAKRISMOTT 3y agoIf 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.
- kaba0 3y ago(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)
- dangerlibrary 3y agoThis 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. ;)
- jstimpfle 3y agoAs an outsider, is panic() like assert()?
- PuercoPop 3y agoIt is like printf to stderr and exit(1)
- bluejekyll 3y agoassertions often get turned off in production/release code, panics do not.
- baby 3y agoNot in Rust. You can use debug_assert if you don’t want to assert in prod tho
- bluejekyll 3y agoI meant generally, you are absolutely correct about rust.
- deleted 3y ago[deleted]
- gpm 3y agoassert!(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.
- justinpombrio 3y agoSay 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
- dangerlibrary 3y agoMaybe 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.
- defen 3y agoThe 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".
- justinpombrio 3y agoThe 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.
- compscigirl 3y agoPanics have a place in systems programming — all operating systems panic when fundamental guarantees are violated.
- CyberDildonics 3y agoI think you mean that CPUs have low level exceptions/interrupts. 'Panic' in this case is a rust specific term and is higher level.
- yencabulator 3y agoAnd you'll find equivalent panics in e.g. Linux.
- jmalicki 3y agopanic 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.
- compscigirl 3y agoPanic 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.
- efficax 3y agoThis is the right answer. A panic is a bug. It's always a bug.
- burntsushi 3y agoCertainly not. See: https://blog.burntsushi.net/unwrap/#why-not-return-an-error-instead-of-panicking https://blog.burntsushi.net/unwrap/#why-not-return-an-error-... But also the rest of the blog post should help clear up the confusion.