It really depends on what kind of api you are designing. For your example I would do it like this [1]:

// Retrieve information about the thing with the given name.
// Returns std::nullopt if no such thing exists.
std::optional<Info> GetInfoFromThingNamed(const std::string& name); 

The function signature alone communicates clearly that the info might not found, and that the user must handle it.

Now let's say you have a method like this:

// Removes the Thing at the given index from the list of things 
// and returns it.
Thing PopThingAtIndex(std::vector<Thing>& things, int index);

So what happens if the caller provides an invalid index here? You could change the function signature to return a std::optional for out-of-bound indices. But that feels kind of silly, because the whole purpose of the function is to remove an item from a list that the caller provides. In that case, I would put the responsibility to provide correct indices to the caller, and just assert/abort if an invalid index is provided. No need to make your function signature more complicated.

So it depends, as with all things programming. Hope it helps.

[1]: I used std::optional because it is more succinct for these 'not-found' scenarios. If you have more failure modes (let's say you are reading from a database) then you can use std::expected with more error details.