Hacker News new | ask | show | jobs
by simion314 1508 days ago
I agree, so Am I wrong or the issue seems to be community culture thing, where some developers panic too eagerly? Say I make a library for resizing images and I have one public function resizeImage(options) , a good developer would think that maybe my code code has a bug and some function from standard library would panic, I should ensure I catch this and my public function never panics (even if there is no memory,disk or whatever Ias an author I should try not to intentionally panic" where a bad Rust developer thinks like " this will never panic unless I made a bug, if I amde a bug I am happy to panic and crush some sucker program so I get the bug report and fix the bug".

There are always bugs(logic bugs where Rust can't protect you) so why not have a clean interface?

2 comments

IO errors like running out of disk space would be handled by returning a `Result` type, not by panicking. Often, Rust code/libraries panic on out-of-memory errors because recovering from that isn't a priority for most application code. But if you are writing lower-level or high-reliability code and you do want to handle out-of-memory errors, the Rust standard library (and many third-party libraries) offer alternative fallible memory allocation APIs that return `Result` instead of panicking on out-of-memory.
I disagree.

A good developer will crash the program, as soon as possible, if and only if it has a bug. If you want to write a program that never crashes, then you need to write a program with no bugs.

The reason you don’t want buggy code to limp along after it detects a bug, is that crashing isn’t the worst possible thing.

The worst possible thing is getting stuck in an infinite loop or a deadlock.