Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Honestly, I don't think libraries should ever panic. Just return an UnspecifiedError with some sort of string. I work daily with rust, but I wish no_std and an arbitrary no_panic would have better support.



Example docs for `foo() -> Result<(), UnspecifiedError>`:

    # Errors

    `foo` returns an error called `UnspecifiedError`, but this only
    happens when an anticipated bug in the implementation occurs. Since
    there are no known such bugs, this API never returns an error. If
    an error is ever returned, then that is proof that there is a bug
    in the implementation. This error should be rendered differently
    to end users to make it clear they've hit a bug and not just a
    normal error condition.
Imagine if I designed `regex`'s API like this. What a shit show that would be.

If you want a less flippant take down of this idea and a more complete description of my position, please see: https://burntsushi.net/unwrap/

> Honestly, I don't think libraries should ever panic. Just return an UnspecifiedError with some sort of string.

The latter is not a solution to the former. The latter is a solution to libraries having panicking branches. But panics or other logically incorrect behavior can still occur as a result of bugs.


Funny that as a user of this library, I would just unwrap this, and it results in the same outcome as if library panicked.


Yes. A panic is the right thing to do, and it's just fine if the library does it for you.


My main issue with panics is poor interop across FFI boundaries.


This is like saying, "my main issue with bugs is that they result in undesirable behavior."

Panicking should always be treated as a bug. They are assertions.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: