Hacker News new | ask | show | jobs
by steveklabnik 3896 days ago
The idea is that Err is good if it's a recoverable error, but if it's not recoverable, you should panic!.

Most errors are recoverable. panic! is an antipattern in a library. Or at least, provide both a panic-ing and a non-panic-ing variant.
2 comments
Gankro 3896 days ago
We specifically recommend against providing panicing and non-panicking. This causes horrible combinatoric explosions. There's very few exceptions to this (array indexing being the major exception). We do of course recommend non-panicking, but there's a few cases where the burden of checking for errors is too high (indexing, refcell).

We're actually in the midst of arguing whether to violate this convention and do it for RefCell: https://github.com/rust-lang/rust/issues/27733

link
steveklabnik 3896 days ago
Yeah, I was thinking of things like array access. The stuff that's on the wrong end of the cost/benefit ratio.
link
fauigerzigerk 3896 days ago
The problem is that a function cannot know whether or not the caller can recover from a particular error, so there's no point in making that distinction in the first place.
link
steveklabnik 3896 days ago
It's part of your API design, if they are recoverable or not. You should lean towards recoverable: if the caller can't recover, they can always do something with it. But some kinds of problems are non-recoverable.
link
fauigerzigerk 3896 days ago
Can you name one such unconditionally unrecoverable problem?
link
steveklabnik 3896 days ago
Say you have a library which has some kind of internal state, and the consistency of said internal state is important for memory safety, as other operations rely on it.

Using assert! to verify that your state is consistent is useful, in case you have a bug. But since it's all internal, it's not something that the caller can really recover from, either. It's not their fault, it's yours.

link
krisdol 3895 days ago
Well here's my issue with this explanation that I've heard a lot: the caller may or may not be able to recover from it, but the caller may still be doing something with the error. Maybe the caller doesn't want to expose the error to its caller, or maybe the caller wants to build a new message to explain the cause of your error. But to panic! takes away a lot of options for the caller.

Worst of all, it leads to untestable code, because the calling test case can't properly check the error against some known result.

link
Gankro 3895 days ago
Is this not a ridiculous thing for an application to check for? That the library it's using detected that it contains a bug?
link