An exception-safe wrapper for std::stoi

Question

std::stoi may throw exceptions so it needs to be surrounded by try/catch.

In applications where std::stoi may be used frequently, it could be useful to have a wrapper.

Is this good practice?

int _stoi(std::string str, int* p_value) {
    // wrapping std::stoi because it may throw an exception

    try {
        *p_value = std::stoi(str);
        return 0;
    }

    catch (const std::invalid_argument& ia) {
        //std::cerr << "Invalid argument: " << ia.what() << std::endl;
        return -1;
    }

    catch (const std::out_of_range& oor) {
        //std::cerr << "Out of Range error: " << oor.what() << std::endl;
        return -2;
    }

    catch (const std::exception& e)
    {
        //std::cerr << "Undefined error: " << e.what() << std::endl;
        return -3;
    }
}

Answer 1

This wrapper effectively removes some of the available functionality from std::stoi() because its signature is

int stoi(const std::string& str, std::size_t* pos = 0, int base = 10);

Because your wrapper does not allow a pos or base argument you cannot use it to give you the number of characters processed (with pos) nor to convert using a different base. std::stoi() provides default values for these arguments so you'd only have to provide them if you need the non-default behavior.

Also, you don't take the std::string argument by const reference like std::stoi() -- the string argument is probably not too expensive to copy in this context but why not accept the argument the same way std::stoi() does?

For completeness, I would also implement the overload of std::stoi() which accepts a std::wstring (and possibly std::stol() and std::stoll()).

I would also avoid the leading underscore, as identifiers with a leading underscore are reserved.

With these suggestions the wrapper would be implemented as

int stoi(const std::string& str, int* p_value, std::size_t* pos = 0, int base = 10) {
    // wrapping std::stoi because it may throw an exception

    try {
        *p_value = std::stoi(str, pos, base);
        return 0;
    }

    catch (const std::invalid_argument& ia) {
        //std::cerr << "Invalid argument: " << ia.what() << std::endl;
        return -1;
    }

    catch (const std::out_of_range& oor) {
        //std::cerr << "Out of Range error: " << oor.what() << std::endl;
        return -2;
    }

    catch (const std::exception& e)
    {
        //std::cerr << "Undefined error: " << e.what() << std::endl;
        return -3;
    }
}

Answer 2

int _stoi(std::string str, int* p_value) {

Identifiers that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

I would expect the signature of your _stoi to match that of the std::stoi you are wrapping. So you should take the std::string by reference-to-const, take an in-out parameter to indicate how much of str was processed, and the base you are converting to.

---

    try {
        *p_value = std::stoi(str);
        return 0;
    }
    catch (...) {
        return -3;
    }

Instead of returning integers that represent error-codes, leverage the type-system. There are a class of types called "either" types that let you return a result or an enumerated error. There are also variant types that let you return one of multiple types of return or error values.

If you plan on supporting the full set of std::stoX family of functions and their overloads between std::string and std::wstring, I urge you to look at lippincott functions as well as variadic argument passing.

Answer 3

Your function signature is misleading. You give almost the same than the std version. It's not obvious that the return type isn't the result.

int _stoi(std::string str, int* p_value)
 // std version, where size_t is an unsigned int
int stoi( const std::string& str, std::size_t* pos = 0, int base = 10 );

So both can be called from a string and a ptr to an (unsigned) integer and return an integer.

• identifiers beginning by an underscore are reserved. If you want to avoid name collisions, you can (and should) enclose your function in a namespace.
• Don't pass your string by value, instead get a const& or a string_view
• Instead of magical return values, you can return an enum.
• Or, even better, you can, maybe, wrap the return value in a sum type like expected or optional.
• Here, if user don't want exceptions, he still have to pay for it, you are just simply hiding them. Your code isn't "exception-free", but "exception-safe".
• It would be better if internally you do the work in a exception-safe way. So, people who deactivated exceptions can still use your function.
• Which advantage versus std::from_chars?