I'm building a backend API to a game. The user (frontend) requests an action and the backend performs the action, if legal. It needs to return a message to the frontend to let it know whether it needs to update the display.
It's okay if the move isn't legal. So Err doesn't feel right here.
I was originally thinking to have every function return a bool for success. But I might later want to return a payload of some type. And the bool/int return is kinda a C mindset, right?
Personally, Result feels reasonable to me here: Ok(...) means the command was accepted and an update is required, but Err(...) means something prevented the command from happening.
You can always define your own enum with more appropriate names, though:
I'm not really experienced in error handling, but if I use Err in cases that are not 'real' errors, i.e. exceptions, doesn't it dilute the meaning when a real Err occurs?
Technically, all an Err is is a signal (which a caller is not allowed to ignore) that the fn/method that returned it failed, conceptually speaking. If that isn't what it would mean for your code, then you're correct, it would dilute the meaning.
However, if you have modeled it conceptually as a failure, then Err is fitting.
There's also a practical concern: since Err takes an argument, that can be potentially expensive, depending on what the argument is. For example, a String argument would cause an allocation for every Err you create.
Neither using Option nor defining your own enum with the shape of Option but different variant names have that issue.
However, you get to choose the argument type of Err. If you make it something like () or an enum with no parameters to its variants the cost is negligible: any enum is always sized by the largest of its variants (plus some space to specify which variant).