The question here is not about if finding something should or should not throw an exception or return null, it is about how to name your methods.
It used to be so that IDE's weren't really a thing. This made it sort of okay to for instance include the return type in the method names (for the developer to remember what it's going to do). You would have something like
public string StringFindItemNameInDomain()
You could also include public/private info. I believe, but don't quote me on this, that it is still common practice in c++ to prefix private member names with m_. Nowadays you hover on a method call and get all the information you need. The access, return type and params.
The problem you are having has to do with optimization/redundency. You want to optimize your method name for readability but don't want to have redundancies.
This ties into the IDE hovering features because if I see a call like
I hover my mouse above it and notice the itemName parameter, I now know what it does. However when I see a call to
I don't need to hover, I can read that as is. I think this is a matter of taste/style.
However, we might want to try and find other things in the domain as well. This is where it gets interesting. If a type in C# supports it, the method is always called TryParse/Parse. I only need to know about the existance of these 2 methods.
If you add another method to our current example like
public bool TryFindCarInDomain(out Car car)
Now I need to know that there are 2 methods.
If I refactor those methods to this:
public bool TryFindInDomain(out string itemName)
public bool TryFindInDomain(out Car car)
The compiler takes care of the types, I only need to know about 1 method signature that I can use to find stuff of certain types. If I ever need to find type x in there, I just try it. If the compiler tells me the type isn't available, I add another method for type x.
Therefore in my opinion it is better not to include itemName in the signature.