7

We can return a tuple

std::pair<bool, std::string> fooFunction();

but that makes code redundant when creating the return value , and force callers to handle the tuple (easy with structural binding in c++17)

if ( okayCondition)
    return {true, {}}; 
else 
   return { false, "blabla error"};

or we can use

std::optional<std::string> fooFunction();

Which is interesting for existing functions returning bool because mostly the callers would not need update thanks to the std::optional operator bool

//Legacy code ok
if (fooFunction())

I am aware of an heavier approach, a templated ReturnStatus class that throws in case the caller does not test the return status value.
Is there any other approach ?

sandwood
  • 2,038
  • 20
  • 38
  • 1
    What do you mean by "best"? Least code? Most robust? Fastest? ...? – NathanOliver Nov 09 '20 at 16:18
  • While this is an interesting question, answers to this question are going to be primarily based on opinion, rather than fact. As such, this question is not really a good fit for SO. I'm voting to close the question. – cigien Nov 09 '20 at 16:26
  • yea closeing is the right choice, where would we be if we needed to have an opinion on things rather than answering questions that 90% of the times could be answered by googling it. – Harald Scheirich Nov 09 '20 at 16:30
  • I recommend passing a status variable, and an error stream parameter. The status would be an `enum`. The error stream allows the function to emit a more detailed description of the error. This is very useful when debugging. – Thomas Matthews Nov 09 '20 at 17:41

2 Answers2

2

You could consider returning a std::error_code from your function.

Using this class you can provide a std::error_code::value which you can use for error handling and a std::error_code::message to display info to the user if there is anything actionable or informative.

Cory Kramer
  • 114,268
  • 16
  • 167
  • 218
  • I would consider this for new projects and particularly interesting for API (because caller does not have to handle specific error). But I see a big problem with it for usage with legacy code returning bool value : the bool operator return true if the code is 0 (liker errno indeed), so all the caller logic must be inverted. And also no way to dynamically create the error message with variable name – sandwood Nov 12 '20 at 12:51
-3

The C++ way to do things is to not return a status at all. If there's an error, throw an exception. Error codes are so 1980's.

Mark Ransom
  • 299,747
  • 42
  • 398
  • 622
  • The standard library takes an opposite approach to this in many cases... – NathanOliver Nov 09 '20 at 16:22
  • 2
    Exceptions are only for exceptional errors, not for common errors. – Lily Nov 09 '20 at 16:23
  • 2
    Couple links to relevant holy wars https://stackoverflow.com/questions/99683/which-and-why-do-you-prefer-exceptions-or-return-codes and https://stackoverflow.com/questions/1849490/c-arguments-for-exceptions-over-return-codes since this tends to be a controversial debate – Cory Kramer Nov 09 '20 at 16:24
  • @CoryKramer thanks, those links were interesting. – Mark Ransom Nov 09 '20 at 16:30